pypyme-giotto — Lista de desarrollo para el sub-proyecto 'Giotto' (estándares,elem. comunes,...)

Re: [pyPYME-Giotto] Ficha-Lista con muchos registros excede al =?ISO-8859-1?Q?tama=F1o?= del contenedor.

[Jose <coo...@py...>]

El mar, 19-07-2005 a las 20:13, Marcelo G Ametller escribi=F3:
> Cuando despliego una ficha/tipo lista, por ejemplo la de paises, que
> tiene muchos registros, visualmente, el la cantidad de renglones de la
> misma excede el tama=F1o de la ventana que la contiene, quedando los
> registros fuera de visual.

En ese caso deber=EDa aparecer una barra de scroll vertical para
permitirte recorrer la lista manualmente. =BFNo es as=ED?

[pyPYME-Giotto] Campo txtCode obligatorio en las fichas...

[Marcelo G A. <mam...@gm...>]

Cuando estuve desarrollando la ficha para customers_contacts, al no
tener esta un campo -codigo- ,  note que en
talasa/core/cadr/decorator-common.py se referencia a ctl-first-field
con txtCode y este no siempre estara... como campo. Como lo
definiriamos para que sea cualquier campo el primero a mostrar de
forma global?

Ademas el txtCode que busca, debe estar definido en controllers o en
la capa view?

--=20
Marcelo Ametller
www.maramsis.com.ar - www.aeroenlace.com.ar
Ubuntu Linux User.

[pyPYME-Giotto] =?ISO-8859-1?Q?Ficha-Lista_con_muchos_registros?= =?ISO-8859-1?Q?_excede_al_tama=F1o_del_contenedor.?=

[Marcelo G A. <mam...@gm...>]

Cuando despliego una ficha/tipo lista, por ejemplo la de paises, que
tiene muchos registros, visualmente, el la cantidad de renglones de la
misma excede el tama=F1o de la ventana que la contiene, quedando los
registros fuera de visual.

Re: [pyPYME-Giotto] =?ISO-8859-1?Q?=C1rea?= de Trabajo

[Jose <coo...@py...>]

El mi=E9, 13-07-2005 a las 17:56, Cesar Pablo Verdes escribi=F3:
> Gente, con la idea de explicar mejor la diferencia entre el MDI
> tradicional y la soluci=F3n propuesta les adjunto un diagrama de lo que
> podr=EDa ser las subareas del Aera de Trabajo:
>=20
[snip]
>=20
> En la parte superior del =C1rea de trabajo se encuentra el T=EDtulo de =
la
> tarea activa (la =FAnica en la que puede trabajar el usuario y sobre la
> que tiene que enfocar su atenci=F3n).
>=20
> Inmediatamente debajo del T=EDtulo de la Tarea est=E1 la Barra de
> Herramienta de la Tarea. En esta zona se colocar=EDan los botones para
> acceso r=E1pido a funciones secundarias de la tarea (La unica accion
> principal, claramente definida por el t=EDtulo de la tarea se ejecuta
> con el bot=F3n de Ok de la Barra de Herramientas de pyPYME... o
> presionando su tecla de acceso r=E1pido).
> Cabe recordar que al activar una tarea, =E9sta podr=EDa agregar element=
os
> propios al men=FA principal, los cuales ser=E1n autom=E1ticamente retir=
ados
> por la interfaz gr=E1fica al desacrivarla. En estos elementos de men=FA=
 se
> pueden repetir funcionalidades de las funciones de la barra de
> herramienta y agragar otras que por espacio no entran.

Hasta aqu=ED, de acuerdo.

> Debajo de la Barra de Herramienta de la Tarea se encuentra la p=E1gina
> de la tarea. Propongo dise=F1ar las vistas de forma de pensarlas en
> p=E1ginas como si fueran p=E1ginas web (basicamente porque los usuarios
> est=E1n acostumbrados a este tipo de visualizaci=F3n y enfoca a los
> programadores a pensar en la cantidad de informaci=F3n mostrada y
> ahorrar ancho de banda caso instalar pyPYME en una tipolog=EDa de
> n-capas).

As=ED se est=E1 planteando y desarrollando. S=F3lo que, adem=E1s de mostr=
arse
como "p=E1ginas web" los llamados "formularios-lista" y
"formularios-ficha" tienen la capacidad de dise=F1arse y mostrarse como
ventanas de tipo di=E1logo (algo que es vital para implementar procesos
multi-paso, como la generaci=F3n de un albar=E1n o de una factura).

> En el =E1ngulo inferior derecho (entre ambas barras de desplazamiento)
> se encuentra un =EDcono que permite visualizar el "=C1rea de Trabajo" a
> pantalla completa, escondiendo el t=EDtulo de la Interfaz, el men=FA
> principal, la barra de de herramientas de pyPYME y el Area de
> Servicios; solo dejando la Barra de Estado que es donde el sistema
> muestra mensajes e interact=FAa con el usuario a medida que ejecutar la
> tarea.

Me temo que Qt no permita esta funcionalidad y, al menos yo, para
procesos de mantenimiento de datos como es una gesti=F3n comercial, no le
veo qu=E9 utilidad pueda aportar una vista a "pantalla completa". Tal vez
en la parte anal=EDtica, que aglutina muchos datos en una sola vista, en
modo consulta y no permite realizar ninguna acci=F3n adicional...

> En la parte Inferior es donde se encuentran las "pol=E9micas" solapas
> mostrando otras tareas que el usuario dej=F3 en "suspenso" y que puede
> retomar o cerrar.
> Suguiero que el administrador pueda, por configuraci=F3n limitar la
> cantidad m=E1xima de tareas en suspenso que un usuario pueda tener
> abiertas. Un n=FAmero de 4 (cuatro), adm=E1s de la tarea activa, parece
> razonable.

Independientemente de si se pueda realizar o no, a m=ED me parece una
buena idea.

Jose

Re: [pyPYME-Giotto] Ideas concretas

[Jose <coo...@py...>]

El mi=E9, 13-07-2005 a las 04:02, Cesar Pablo Verdes escribi=F3:
> El =C1rea de Servicios servir=EDa para ubicar todo aquello que no es un=
a
> vista de una tarea funcional de pyPYME pero que ayuda al usuario a
> encontrar la tarea o elemento con el que desea trabajar, as=ED como
> tambi=E9n interactuar con sus compa=F1eros de trabajo.
>=20
> En la parte superior se encuentran iconos. Al elegir uno de ellos la
> parte de abajo (la verde lisa) desarrolla la selecci=F3n del usuario.
>=20
> Vemos los iconos propuestos:
>       * =C1rbol de tareas de los m=F3dulos instalados:
>         Permite buscar una tarea entre las que tiene posibles ejecutar
>         el usuario logoneado seg=FAn sus permisos.
>         En algunos sistemas como SAP existe la posibilidad de que el
>         administrador defina un men=FA especial seg=FAn el perfil o
>         usuario. Si no lo hace se muestra todo el =E1rbol de opciones
>         instaladas, pero no se le permite ejecutarla tras ser
>         seleccionada con un mensaje de error de permiso de acceso.
[snip]
>         Detro del =C1rea de Servicio se despliegan los campos para
>         realizar la b=FAsqueda por descripci=F3n de la tarea. El campo =
de
>         b=FAsquda es un combo desplegable donde se muestran las =FAltim=
as
>         b=FAsqudas del usuario.
>         Al realizar la b=FAsqueda (tipo google simplificado con palabra=
s
>         claves, frases, palabras obligatorias, etc) se abren las ramas
>         que tengan tareas que cumplan la condici=F3n de b=FAsqueda y al
>         presionar el bot=F3n de largavista el sistema ir=E1 posando la
>         seleccion sobre las tareas en forma c=EDclica.
>        =20
>         Debajo del =E1rbol de tareas (en esta imagen ejemplificado con
>         un arbol de directorios y un archivo) se encuentra una barra
>         herramientas espec=EDfica con los siguientes =EDconos de izquie=
rda
>         a derecha:
>              1. Colapsar la rama del arbol seleccionada
>              2. Colapsar todo el arbol
>              3. Expandir la rama del arbol seleccionada
>              4. Expandir todo el arbol
>              5. Comenzar la tarea en el =C1rea de trabajo, cancelando l=
a
>                 tarea que est=E9 activa en ese momento (previa consulta
>                 con un d=EDalogo de confirmaci=F3n de ser necesario)
>              6. Comenzar la tarea en una nueva solapa dentro del =C1rea
>                 de trabajo de la misma ventana de la interfaz gr=E1fica
>              7. Abrir una nueva ventana (con todas sus =E1reas) y
>                 comenzar la tarea seleccionada en el =C1rea de Trabajo

Teniendo en cuenta que es el propio usuario o el administrador designado
a tal efecto los que deciden qu=E9 m=F3dulos y componentes instalar y
activar y que dichas elecciones se reflejan en la confecci=F3n din=E1mica
del men=FA de la aplicaci=F3n, de los "accesos directos" de la barra de
m=F3dulos y del "=E1rbol de operaciones", no creo que sea necesario inclu=
ir
un proceso de b=FAsqueda de tareas.

Tu idea me parece buena en situaciones en las que los procesos no
presentan una estructura clara (en el caso de pyPYME s=ED, ya que la
funcionalidad se agrupa en componentes y =E9stos en m=F3dulos) o en los q=
ue
la magnitud del aplicativo hace necesaria dicha capacidad.

>       * Tareas relacionadas con la tarea actual:
>         Para cada tarea los programadores pueden indicar otras tareas
>         asociadas que usualmente los usuarios utilizan simultaneamente
>         o tras completar la tarea corriente.
>         Por ejemplo, si el usuario est=E1 cargando una factura de venta=
,
>         puede necesitar acceder a la cuenta corriente del cliente, los
>         datos del mismo, alg=FAn detalle de un art=EDculo, etc. Para
>         evitar que el usuario tenga que buscar la tarea entre todas
>         las posibles en el arbol del sistema, al utilizar este
>         servicio se muestra una serie de "links" =FAtiles a otras
>         tareas.
>         Una visi=F3n posible podr=EDa ser:
>             TBD
>        =20
>         Nota: Al profundizar el an=E1lisis he eliminado la opcion
>         "Elementos relacionados con la tarea o elemento actual" ya que
>         me pare innecesario. A la larga siempre se hacen una tarea
>         sobre los elementos.

Pues tu idea de mostrar una lista de tareas complementarias a la que se
est=E9 realizando me parece bastante buena, aunque no entiendo qu=E9 quie=
res
decir con "A la larga siempre se hacen una tarea sobre los elementos".

>       * Links a las tareas preseleccionadas por el usuario:
>         El concepto de este servicio de la interfaz gr=E1fica es que el
>         usuario se arme su propio conjunto de links a tareas de su
>         preferencia... pudiendo organizarlas en forma de =E1rbol, si es
>         que lo desea.
>         Una visi=F3n posible podr=EDa ser:
>             TBD

Ok.

Esto formar=EDa parte del m=F3dulo de personalizaci=F3n, que deber=EDa
realizarse despu=E9s de haber desarrollado toda la funcionalidad b=E1sica=
.

Si te fijas en mi comentario al punto anterior-anterior observar=E1s que
yo he planteado la posibilidad de que el usuario pueda confeccionar
(indirectamente) la estructura de men=FAs y de la "barra de m=F3dulos"
simplemente seleccionando qu=E9 componentes y m=F3dulos quiere activar. T=
u
sugerencia ir=EDa un paso m=E1s all=E1.

>       * Enviar mensajes a otros usuarios conectados y ver los mensajes
>         recibidos por otros usuarios:
>         Este servicio de la interfaz gr=E1fica prestar=EDa servicios
>         similares al MSN, aunque acotados a mensajes de texto e
>         im=E1genes de pantallas de la tarea activa en el =C1rea de Trab=
ajo
>         y solamente entre usuarios del sistema.
>         Esta funcionalidad surge de que hay empresas que no permiten
>         sistemas p=FAblicos de mensajer=EDa, pero es una herramienta mu=
y
>         =FAtil para uso interno.
>         Adisionalmente facilitar=EDa el soporte remoto por parte de
>         usuarios expertos.
>         El usuario podr=EDa elegir enter buscar un usuario en el arbol
>         organizacional de toda la empresa, por orden alfab=E9tico, o
>         armar su propio grupo de usuarios pudiendo organizarlos en
>         forma de =E1rbol, si es que lo desea.
>         Una visi=F3n posible podr=EDa ser:
>             TBD

El soporte para grupos de trabajo no pertenece al dominio de la
aplicaci=F3n de pyPYME (al fin y al cabo "s=F3lo" pretende solucionar la
gesti=F3n comercial de una peque=F1a-mediana empresa). No niego que pueda
ser =FAtil, pero se trata de una funcionalidad que no creo que debamos
desarrollar.

Jose

Re: [pyPYME-Giotto] Ancho de banda limitado

[Cesar P. V. <ces...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=iso-8859-15"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jose wrote:
<blockquote cite="mid...@de..."
 type="cite">
  <pre wrap="">El mié, 13-07-2005 a las 04:45, Cesar Pablo Verdes escribió:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Por ejemplo, si bien puede ser muy comodo para el usuario desplegar la
lista completa de clientes para elegir uno de ellos (enfoque comun en
aplicaciones con arquitecturas de una y dos capas) puede ser
terriblemente ineficiente para n-capas con ancho de banda limitado.
Una solución (que por ejemplo implementa SAP) es manejar códigos para
ubicar elementos (clientes, facturas, materiales, etc), y si el
usuario no sabe el código o no lo recuerda y necesita ayuda para
buscar un elemento en particular, presentar primero una ventana de
filtro de búsqueda (SAP las llama match-codes) antes de mostrar ningun
set de elementos, y siempre que fuera posible limitar la cantidad de
elementos a un valor máximo (ejemplo 100 o 1000) a devolver a la
interfaz gráfica, avisando al usuario que se devuelve una cantidad
limitada del conjunto resultante a su búsqueda.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Coincidimos en este planteamiento.

Mi idea es que, por cada lista de registros (gestionada en un
"formulario-lista") habrá un proceso de "búsqueda rápida" por uno de
varios conceptos y un proceso de "búsqueda avanzada" asistida mediante
un formulario especial.

Sólo tengo una duda y tiene que ver con la carga inicial de registros:
algunos mantenimiento siempre gestionarán pocos registros, por lo que
parece conveniente cargarlos inicialmente (al mostrar el
"formulario-lista" quiero decir); en cambio otros pueden mover gran
cantidad de datos, por lo que parece conveniente o realizar una carga
inicial acotada o no realizar ninguna carga. Y como siempre conviene
proceder de una forma uniforme...
  </pre>
</blockquote>
Tienes razón, en el caso de gestionar pocos registros (ejemplo paises)
no tiene sentido aumentar la burocracia con pantallas y filtros previos.<br>
<br>
Totalmente de acuerdo.<br>
<br>
C.<br>
</body>
</html>


	

	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 

Re: [pyPYME-Giotto] Ideas concretas

[Cesar P. V. <ces...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=iso-8859-15"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jose wrote:
<blockquote cite="mid...@de..."
 type="cite">
  <blockquote type="cite">
    <pre wrap="">      * La Barra de Titulo será el título de la ventana del sistema
        operativo. Como título de la ventana se colocará "pyPYME -
        Bienvenido Cesar Verdes", donde "Cesar Verdes" es el nombre
        largo del usuario logoeado.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Es una opción, aunque muchas aplicaciones prefieren incluir en el título
la operación en curso y en una posición fija dentro del formulario
principal el usuario logeado. Yo, aunque sólo sea por seguir esta
costumbre, también prefiero hacerlo así.
  </pre>
</blockquote>
He visto muchos sistemas como la estructura a la que tu te refieres,
inclusive en muchas aplicaciones basados en páginas HTML.<br>
<br>
En mi mail anterior titulado "[pyPYME-Giotto] Área de Trabajo" propuse
reservar la parte superior del "Area de Trabajo" para el título de la
operación en curso.<br>
Esta idea surge de sugerencias de:<br>
<br>
- Intuitive User Interface (de Microsoft):<br>
<blockquote>Donde le dan mucha importancia al título. Te copio parte de
un documento que creo estar relacionado:<br>
</blockquote>
<blockquote>"<i><u>Making the screen title prominent</u></i><br>
  <i>Once you settle on a useful screen title, it's important to make
sure the user sees it. Some studies have shown that users rarely read
instructional text. To help overcome this problem, screen titles should
be designed to be prominent and appealing in order to draw the user's
attention. The screen's visual design should inform the user that the
title is the most important thing to be read.</i>"<br>
</blockquote>
<blockquote>Pantallas de IUI que Microsoft pone como ejemplo son las
siguientes:<br>
  <table border="0" cellpadding="2" cellspacing="2" width="100%">
    <tbody>
      <tr>
        <td align="center" valign="top"><img alt=""
 src="cid:par...@ya..." height="218" width="294"><br>
        </td>
        <td align="center" valign="top"><img alt=""
 src="cid:par...@ya..." height="216" width="293"><br>
        </td>
      </tr>
    </tbody>
  </table>
  <br>
</blockquote>
- SAP evolucionó su interfaz de la estructura que tu planteas para una
similar a la planteada en IUI.<br>
<blockquote>En la version R3 tenía el título de la tarea en la barra de
título de la ventana:<br>
  <img alt="" src="cid:par...@ya..."
 height="626" width="708"><br>
</blockquote>
<blockquote><br>
Y luego de la versión 4.0 pasó a tener el título de la operación en
letras grandes azules sobre un fondo blanco debajo de la barra de
herramientas del sistema.<br>
  <br>
Te anexo una pantalla de la versión 4.6:<br>
  <img alt="" src="cid:par...@ya..."
 height="484" width="700"><br>
</blockquote>
<blockquote>Inclusive como puedes observar en la imagen, en la nueva
interfaz gráfica SAP eliminó la barra de título de la ventana <span
 class="moz-smiley-s4"><span> :-P      </span></span> (cosa que creo
más complicado para una solución multiplataforma).<br>
</blockquote>
<br>
Obviamente hay muchas otras interfaces que se estructuran como tu
dices, con el título de la operación en la barra de título de la
ventana.<br>
<br>
Personalmente (y con la mejor explicación teórica que puedo darteles)
propongo colocar el título de la operación en letras grandes y bien
visible al usuario, como lo propuse en el mail del "Area de Trabajo".<br>
<br>
¿Les convence la explicación? ¿Les parece que sigamos adelante sobre
esta base?<br>
<br>
Con respecto al lugar donde colocar el nombre de usuario, sugerí
colocarlo en la barra de título de la ventana principal porque el
sistema "Compiere" lo coloca ahi y porque no se me ocurrió ningún otro
lugar donde colocarlo sin desaprovechar espacio de la ventana ni
mezclar conceptos en otras áreas de la ventana. No tengo ninguna
preferencia teórica.<br>
<br>
¿Alguna sugerencia de donde colocarlo?<br>
<br>
<blockquote cite="mid...@de..."
 type="cite">
  <blockquote type="cite">
    <pre wrap="">      * La Barra de Herramienta de pyPYME tendrá las opciones comunes
        a la navegación del sistema y funcionalidades intrínsicas a la
        UI o comunes a muchas tareas.
        Propongo la siguiente Barra de Herramientas de pyPYME:
    </pre>
  </blockquote>
  <pre wrap=""><!---->[snip]
  </pre>
</blockquote>
¿Que significa [snip]?<br>
<br>
<blockquote cite="mid...@de..."
 type="cite">
  <pre wrap="">En la propuesta que hize y en el código actual la barra de herramientas
que propones está siendo sustituida por una barra "de accesos rápidos"
que permite acceder directamente a la funcionalidad de un módulo. Está
pensado como una forma de agilizar el acceso a una determinada
funcionalidad ya que se trata de una agrupación natural.

Por lo que yo entiendo, la barra de herramientas que propones es una
versión ampliada de la que incluyo en los formularios-ficha y
formularios-lista junto con una versión simplificada de la herramienta
de búsquedas que incluyo en los formularios-lista.
  </pre>
</blockquote>
Jose, me gustaría explicar mejor el concepto propuesto, que difiere en
parte con el que tu planteas en las ventanas SDI de formularios-ficha y
formularios-lista.<br>
En mi propuesta hay basicamente 3 lugares donde el usuario encuentra
"accesos rápidos" y busquedas de tareas:<br>
<ol>
  <li>El Área de la <i><b>Barra de Herramientas del Sistema</b></i>,
donde se ubican "accesos rápidos" comunes a todas las tareas de todos
los módulos, basicamente para ayudar a la navegación y funciones
intrínsicas de la interfaz gráfica.</li>
  <li>El <i><b>Área de Servicios</b></i> donde el usuario puede
encontrar varias formas de buscar y localizar cualquier tarea de
cualquier módulo.</li>
  <li>El Sub-area de la <i><b>Barra de Herramientas de la Tarea</b></i>
en el "Area de Tarbajo", donde el usuario encuentra los "accesos
rápidos" de las tareas y elementos relacionados con la tarea que está
realizando.</li>
</ol>
El concepto de ambas barras de herramientas lo puedes observar en la
imagen de la pantalla de la versión 4.6 y personalmente, como usuario
me resultó muy cómodo.<br>
<br>
Como tu lo dices en tu comentario, la nueva interfaz propuesta difiere
en algunos conceptos de la que tu planteas (y ya estás codificando) en
los formularios-ficha y formularios-lista. Mi intensión con este
estudio y posterior diseño y codificación, es aportar a pyPYME una
interfaz gráfica más completa y autocontenida. Tal vez sea un elemento
más que nos puede ayudar a diferenciar de otras aplicaciones de gestión
para PYMES open source que andan dando vuelta por ahi.<br>
<br>
Necesito que lo concensuemos entre todos. La realidad es que hoy tu
tienes codificado algo concreto (los distintos formularios), en cambio
mis sugerencias y estudios aun no pasan el nivel de borrador de
análisis.<br>
<br>
Tal vez para no complicar el desarrollo actual podríamos abrir una rama
del proyecto (siempre y cuando entre todos acordamos que la interfaz
propuesta es conveniente y utilizable en un futuro de pyPYME) e
incluirla en una revisión posterior a la 1.0<br>
<br>
¿Cual son vuestras opiniones al respecto? ¿Justifica continuar con un
nuevo enfoque de la interfaz gráfica? ¿Es el momento?<br>
<br>
<blockquote cite="mid...@de..."
 type="cite">
  <blockquote type="cite">
    <pre wrap="">        Donde en la parte superior se encuentra una serie de íconos de
        acceso a los servicios.
        Entre los servicios propuestos incluyo de izquierda a derecha:
             1. Árbol de tareas de los módulos instalados
             2. Tareas relacionadas con la tarea o elemento actual
             3. Elementos relacionados con la tarea o elemento actual
             4. Links a las tareas preseleccionadas por el usuario
             5. Enviar mensajes a otros usuarios conectados y ver los
                mensajes recibidos por otros usuarios.
    </pre>
  </blockquote>
  <pre wrap="">Creo que viene a ser algo similar (aunque no entiendo por qué mezclar
tareas y mensajes) a lo que estamos incorporando como "árbol de
operaciones".
  </pre>
</blockquote>
Disculpa, no comprendo bien tu comentario, tal vez la respuesta la haya
dado en el mail en donde intento aclarar a Marcelo su pregunta sobre el
"Área de Servicios".<br>
En caso que no sea así, o no estés de acuerdo, por favor lo charlamos.<br>
<br>
<blockquote cite="mid...@de..."
 type="cite">
  <pre wrap="">En la barra de estado, yo creo, nunca deberían mostrarse mensajes
críticos (advertencias y errores). Sólo mensajes de tipo 'feedback' que
no importa si llegan o no al usuario. Cualquier mensaje medianamente
importante debería ser mostrado mediante una ventana modal, asegurando
así que el usuario es informado.

Sí que es cierto que es un buen sitio donde colocar información
"complementaria" como la fecha y demás.
  </pre>
</blockquote>
Conceptualmente estoy de acuerdo en que en la barra de estado no se
deben muestrar mensajes críticos.<br>
<br>
La idea es solo que cuando el usuario intenta ejecutar una acción con
datos erroneos cargados en los campos de ingreso, la interfaz del
usuario muestre un mensaje de advertencia de que hay errores y/o
advertencias que deben ser corregidas antes de seguir adelante... no el
mensaje de error o advertencia en si.<br>
SAP lo hace en una forma muy interesante y graciosa mostrando un ícono
de error o advertencia que se agranda y luego se achica en el ángulo
inferior izquierdo de la barra de estado, la cual desaparece cuando se
corrigen los datos erroneos.<br>
Pero conceptualmente coincido que (según se detalla en la guia de
estilo de HTMLB):<br>
<ol>
  <li>Se deben mostar el o los campos con datos erroneos en un estado
distintivo (ejemplo el texto en rojo, o lo que se defina según el
diseño)</li>
  <li>Mostrar el mensaje de error o advertencia dentro de la vista lo
más sercano al campo con dato erroneo posible (por ejemplo esto se
puede observar en formulatios HTML donde aparece tras cada campo con
dato erroneo un texto en rojo que indica la naturaleza del error).</li>
  <li>Colocar el cursor/selección en el primer campo con datos erroneos.</li>
  <li>Evitar los Popups (en este punto difiero de tu comentario) ya que
en general molestan a los usuarios y terminan siendo ignorados, dejando
su uso para los errores y advertencias de errores severos que requieran
una intervensión directa de los usuarios</li>
</ol>
Creo que en ambos comentarios hay muchos puntos en comun ¿Estas de
acuerdo? (sobre todo con la diferencia sobre las ventanas modales).<br>
<br>
<br>
Creo que en este mail se plantean diferencias que necesitamos
consensuar. Me encanta el intercambio enriquecedor de ideas!  <span
 class="moz-smiley-s11"><span> 8-) </span></span><br>
<br>
C.<br>
<br>
</body>
</html>

[pyPYME-Giotto] [CHARON] Formularios-lista

[Jose <coo...@py...>]

Hola,

Acabo de subir a SVN [1] una versi=F3n algo m=E1s completa del
formulario-lista (adem=E1s de un m=F3dulo que facilita la visualizaci=F3n=
 de
msgboxes Qt).

Ahora integra el controlador del formulario-ficha dentro del =E1rea de
trabajo del Centro de Control, sustituyendo al formulario-lista, tanto
para la creaci=F3n de nuevos registros como para la edici=F3n del registr=
o
marcado, e incluye la implementaci=F3n de los procesos de borrado de
registros y de refresco de la lista.

Por lo tanto, respecto de los formularios-lista queda por implementar el
filtrado de registros (filtrado avanzado mediante un di=E1logo
espec=EDfico), la impresi=F3n (que dejar=E9 para m=E1s adelante) y la
funcionalidad de los pre-filtros (que dejar=E9 para cuando encontremos el
primer caso de uso).

Respecto a los formularios-ficha queda por revisar toda su operativa
para que implemente las operaciones de mantenimiento.

Saludos,
Jose

[1]http://dev.pypyme.org/trac/changeset/71

Re: [pyPYME-Giotto] Ancho de banda limitado

[Jose <coo...@py...>]

El mi=E9, 13-07-2005 a las 04:45, Cesar Pablo Verdes escribi=F3:
> Por ejemplo, si bien puede ser muy comodo para el usuario desplegar la
> lista completa de clientes para elegir uno de ellos (enfoque comun en
> aplicaciones con arquitecturas de una y dos capas) puede ser
> terriblemente ineficiente para n-capas con ancho de banda limitado.
> Una soluci=F3n (que por ejemplo implementa SAP) es manejar c=F3digos pa=
ra
> ubicar elementos (clientes, facturas, materiales, etc), y si el
> usuario no sabe el c=F3digo o no lo recuerda y necesita ayuda para
> buscar un elemento en particular, presentar primero una ventana de
> filtro de b=FAsqueda (SAP las llama match-codes) antes de mostrar ningu=
n
> set de elementos, y siempre que fuera posible limitar la cantidad de
> elementos a un valor m=E1ximo (ejemplo 100 o 1000) a devolver a la
> interfaz gr=E1fica, avisando al usuario que se devuelve una cantidad
> limitada del conjunto resultante a su b=FAsqueda.

Coincidimos en este planteamiento.

Mi idea es que, por cada lista de registros (gestionada en un
"formulario-lista") habr=E1 un proceso de "b=FAsqueda r=E1pida" por uno d=
e
varios conceptos y un proceso de "b=FAsqueda avanzada" asistida mediante
un formulario especial.

S=F3lo tengo una duda y tiene que ver con la carga inicial de registros:
algunos mantenimiento siempre gestionar=E1n pocos registros, por lo que
parece conveniente cargarlos inicialmente (al mostrar el
"formulario-lista" quiero decir); en cambio otros pueden mover gran
cantidad de datos, por lo que parece conveniente o realizar una carga
inicial acotada o no realizar ninguna carga. Y como siempre conviene
proceder de una forma uniforme...

> Si usamos el XMLRPC para ejecutar funciones y solicitar acotadas
> listas de elementos no veo que sea inconveniente para la eficiencia al
> utilizar bajos anchos de banda.
>=20
> Insisto, es un tema de enfoque de la aplicaci=F3n desde su comienzo y
> personalmente creo que vale la pena tenerlo en cuenta. He visto
> aplicaciones con estructura de dos capas cuya performance empeora
> notoriamente cuando crece la cantidad de informaci=F3n almacenada por u=
n
> mal dise=F1o de vistas y controladores. Una pregunta posible ser=EDa =BF=
Como
> funcionar=EDa este formulario si fuera una p=E1gina web?
>=20
> Por otro lado, mi opinion es que las versiones para interfaces en modo
> texto deben tener vistas y controladores espec=EDficos, considero muy
> complejo (por no decir ut=F3pico) tratar de unicicar el dise=F1o, porqu=
e
> no quedar=EDa otra alternativa que limitar el potencial de la interfaz
> gr=E1fica.

Estoy de acuerdo.

> =C9ste es un tema importante, tiene muchos enfoques y creo que tendremo=
s
> que estudiarlo m=E1s profundamente cuando llegue su momento, sin dejar
> de lado el objetivo al realizar la codificaci=F3n actual.=20
>=20
> =BFEstas de acuerdo?

Yo s=ED.

Jose

Re: [pyPYME-Giotto] Interfaz Grafica

[Jose <coo...@py...>]

El mi=E9, 13-07-2005 a las 04:17, Cesar Pablo Verdes escribi=F3:
> Totalmente de acuerdo con tu cr=EDtica hacia las MDI y a la necesidad d=
e
> presentarle al usuario un bloque de informaci=F3n por vez. Creo que las
> interfaces MDI son una porquer=EDa y en la pr=E1ctica nadie usa m=E1s d=
e un
> documento maximizado por vez.
>=20
> Yo me refiero a otra funcionalidad, a la funcionalidad de
> multi-solapas (disculpa por no saber si tiene un nombre m=E1s t=E9cnico=
).
> Es una funcionalidad similar a cuando ten=E9s varios documentos abierto=
s
> en Eclipse, varias hojas en un libro de Excel, o varias p=E1ginas web a=
l
> navegar con Mozilla.
>=20
> La idea surge de la necesidad que tienen los usuarios de consultar
> cierta informaci=F3n o realizar una tarea suspendiendo la que est=E1n
> haciendo para luego continuarla. Por ejemplo... imagina un usuario que
> est=E1 cargando un documento de despacho y de pronto recibe el llamado
> de un cliente que desea consultar un dato sobre su cuenta corriente.
>=20
> Personalmente veo contraproducente abrir varias ventanas SDI a la vez
> (he llegado a ver usuarios con varias ventanas SDI abiertas de la
> misma tarea sin darse cuenta, inclusive bloqueandose recursos ellos
> mismos entre ventanas). Por eso prefiero la idea de una cantidad
> limitada de solapas (4 =F3 5) que le permita tener 1 (una y solo una)
> tarea activa y 3 =F3 4 tareas en suspenso en otras solapas.
>=20
> =BFLogr=E9 explicar la diferencia con el concepto de MDI? =BFCompartes =
los
> comentarios? =BFTienes alguna sugerencia para mejorar el concepto?

S=ED, queda claro.

Y aunque comparto tus comentarios tengo 2 peque=F1as puntualizaciones:

	- por una parte el problema de abrir varias instancias de una misma
aplicaci=F3n es un problema que se suele resolver controlando que s=F3lo =
1
instancia pueda ejecutarse a la vez. Tomo nota de que se trata de un
control que debemos incorporar

	- por otra, me parece buena idea lo de utilizar "separadores" (como
ves, yo tampoco conozco la traducci=F3n t=E9cnica ;-)) pero creo que es a=
lgo
cuya aplicaci=F3n deber=EDamos aplazarla en tanto no dispongamos de una
infraestructura m=E1s madura. Lo cual no quiere decir que no deba
analizarse como est=E1s haciendo

Jose

Re: [pyPYME-Giotto] Ideas concretas

[Jose <coo...@py...>]

El mar, 12-07-2005 a las 16:20, Patricio Valarezo escribi=F3:
> Me olvidaba!, ya has pensado en alguna soluci=F3n para la interface en=20
> redes con anchos de banda limitados ?, podr=EDamos adaptar la misma=20
> interface o ser=E1 necesario crear alguna alternativa mas liviana (si e=
s=20
> que existe) o en "modo texto",  no tengo experiencia con esto, no se qu=
e=20
> tan efectiva puede resultar la versi=F3n XMLRPC de pyPyme para estos=20
> ambientes. En un futuro me gustar=EDa a mi trabajar en alguna versi=F3n=
 del=20
> POS para dispositivos de mano.

Una de las ventajas de desarrollar un sistema en capas es que puedes
sustituir una sin tener que tocar las dem=E1s.

Esto quiere decir que, en principio, si alg=FAn d=EDa cambiamos el interf=
az
de usuario no tenemos por qu=E9 cambiar el resto del aplicativo
(middleware, modelos, etc). Al menos es as=ED si el =FAnico punto de
contacto ("interfaz", t=E9cnicamente hablando) est=E1 debidamente soporta=
do;
es decir, si el nuevo interfaz de usuario dispone de alg=FAn medio de
realizar XMLRPC (lo cual es bastante probable).

Jose

Re: [pyPYME-Giotto] Ideas concretas

[Jose <coo...@py...>]

El mar, 12-07-2005 a las 01:56, Cesar Pablo Verdes escribi=F3:
> Donde:
>       * La Barra de Titulo ser=E1 el t=EDtulo de la ventana del sistema
>         operativo. Como t=EDtulo de la ventana se colocar=E1 "pyPYME -
>         Bienvenido Cesar Verdes", donde "Cesar Verdes" es el nombre
>         largo del usuario logoeado.

Es una opci=F3n, aunque muchas aplicaciones prefieren incluir en el t=EDt=
ulo
la operaci=F3n en curso y en una posici=F3n fija dentro del formulario
principal el usuario logeado. Yo, aunque s=F3lo sea por seguir esta
costumbre, tambi=E9n prefiero hacerlo as=ED.

>       * El Men=FA Principal ser=E1 el men=FA del sistema pyPYME, con
>         funcionalidades comunes a cualquier tarea, y el men=FA se
>         modifica din=E1micamente al activar una vista en el "Area de
>         Trabajo" la cual puede agregar sus propias opciones de Menu y
>         Submenues.

Ok.

>       * La Barra de Herramienta de pyPYME tendr=E1 las opciones comunes
>         a la navegaci=F3n del sistema y funcionalidades intr=EDnsicas a=
 la
>         UI o comunes a muchas tareas.
>         Propongo la siguiente Barra de Herramientas de pyPYME:
[snip]
>         Donde el significado de los =EDconos de izquierda a deracha son=
:
>              1. Terminar la Tarea
>              2. Cancelar la Tarea
>              3. Ir a la pantalla anterior caso la tarea tenga varias
>                 ventanas, o volver a la pantalla de donde se llam=F3 la
>                 tarea.
>              4. Grabar todos los datos registrados en la tarea hasta
>                 el momento (sin darla por terminada)
>              5. Buscar un tecto en la vista actual
>              6. Imprimir (caso est=E9 habilitada la funcionalidad para
>                 la vista activa)
>              7. Cortar
>              8. Copiar
>              9. Pegar
>             10. Ir a la pantalla principal del usuario (su "home" con
>                 las tareas usadas recientemente, sus tareas
>                 preferidas, los elementos sobre los cuales suele
>                 trajar y otra informaci=F3n que le pueda ser de
>                 utilidad)
>             11. Mostrar u ocultar el =C1rea de Servicios a fin de ganar
>                 m=E1s espacio para el =C1rea de Trabajo
>             12. Ayuda de como realizar la tarea de la vista activa (es
>                 una ayuda contextual que se despliega en el =C1rea de
>                 Trabajo, mostrando en el =C1rea de Servicios ayudas
>                 relacionadas.
>             13. Campo donde el usuario experto puede tipear el c=F3digo
>                 de una tarea para abrirla directamente en el "=C1rea de
>                 Trabajo" (no requiere buscarla en ning=FAn men=FA ni ar=
bol
>                 de tareas). Este campo es un campo desplegable donde
>                 se muestran las tareas ordenando primero las tareas
>                 llamadas recientemente por ese usuario.
>             14. Bloquea la Interfaz Gr=E1fica para que ning=FAn otro
>                 usuario pueda realizar cambios sin cerrar =E1rea ni
>                 tarea. Esta opci=F3n puede ser =FAtil cuando el usuario
>                 desea levantarse de su escritorio por unos minutos.
>             15. Deslogonea al usuario actual, volviendo a la pantalla
>                 de login del sistema.

En la propuesta que hize y en el c=F3digo actual la barra de herramientas
que propones est=E1 siendo sustituida por una barra "de accesos r=E1pidos=
"
que permite acceder directamente a la funcionalidad de un m=F3dulo. Est=E1
pensado como una forma de agilizar el acceso a una determinada
funcionalidad ya que se trata de una agrupaci=F3n natural.

Por lo que yo entiendo, la barra de herramientas que propones es una
versi=F3n ampliada de la que incluyo en los formularios-ficha y
formularios-lista junto con una versi=F3n simplificada de la herramienta
de b=FAsquedas que incluyo en los formularios-lista.

>       * En el =C1rea de Servicios se despliegan opciones =FAtiles de
>         b=FAsquda de tareas y elementos sobre los cuales el usuario
>         desea realizar alguna operaci=F3n.
>         Propongo la siguiente =C1rea de Servicios:
[snip]
>         Donde en la parte superior se encuentra una serie de =EDconos d=
e
>         acceso a los servicios.
>         Entre los servicios propuestos incluyo de izquierda a derecha:
>              1. =C1rbol de tareas de los m=F3dulos instalados
>              2. Tareas relacionadas con la tarea o elemento actual
>              3. Elementos relacionados con la tarea o elemento actual
>              4. Links a las tareas preseleccionadas por el usuario
>              5. Enviar mensajes a otros usuarios conectados y ver los
>                 mensajes recibidos por otros usuarios.

Creo que viene a ser algo similar (aunque no entiendo por qu=E9 mezclar
tareas y mensajes) a lo que estamos incorporando como "=E1rbol de
operaciones".

>       * El =C1rea de Trabajo es donde se despliegan las vistas de los
>         componentes. TBD

Ok.

>       * La Barra de Estado es usada principalmente para que pyPYME
>         envie mensajes al usuario en respuesta a sus acciones
>         (mensajes, advertencias, errores, indicaci=F3n de tarea en
>         proceso, etc) y otra informaci=F3n =FAtil como la hora y el d=ED=
a
>         con posibilidad de desplegar un calendario. TBD

En la barra de estado, yo creo, nunca deber=EDan mostrarse mensajes
cr=EDticos (advertencias y errores). S=F3lo mensajes de tipo 'feedback' q=
ue
no importa si llegan o no al usuario. Cualquier mensaje medianamente
importante deber=EDa ser mostrado mediante una ventana modal, asegurando
as=ED que el usuario es informado.

S=ED que es cierto que es un buen sitio donde colocar informaci=F3n
"complementaria" como la fecha y dem=E1s.

> Nota: Los =EDconos son sacados de la base de =EDconos de SAP, luego
> podemos solicitar la ayuda de un dise=F1ador gr=E1fico para darle una
> personalidad =FAnica a pyPYME.

S=ED, si encontramos alg=FAn dise=F1ador que desee participar 8-).

Jose

[pyPYME-Giotto] =?UTF-8?B?w4FyZWEgZGUgVHJhYmFqbw==?=

[Cesar P. V. <ces...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
 Jose wrote:<br>
<blockquote cite="mid...@ya..." type="cite">
  <blockquote cite="mid...@de..."
 type="cite">
    <pre wrap="">
No.

Eso es lo que hacían los diseños MDI que están siendo sustituidos (tanto
por Microsoft como por otros grandes fabricantes) por un diseño SDI que
incluye navegación e integración de contenidos.

Hace tiempo leí unos estudios (lo siento, no recuerdo cuáles) en los que
se concluía, dada la limitada capacidad visual y de memorización del ser
humano, que era mejor presentar un único bloque informativo (p.e. la
ficha de un cliente, una factura, un ingreso en caja, etc) que varios.

Supongo que en alguno de estos estudios de interfaz hombre-máquina es en
lo que se han basado los expertos de Microsoft y demás.
    </pre>
  </blockquote>
</blockquote>
Gente, con la idea de explicar mejor la diferencia entre el MDI
tradicional y la solución propuesta les adjunto un diagrama de lo que
podría ser las subareas del Aera de Trabajo:<br>
<br>
<img alt="" src="cid:par...@ya..." height="438"
 width="570"><br>
<br>
En la parte superior del Área de trabajo se encuentra el Título de la
tarea activa (la única en la que puede trabajar el usuario y sobre la
que tiene que enfocar su atención).<br>
<br>
Inmediatamente debajo del Título de la Tarea está la Barra de
Herramienta de la Tarea. En esta zona se colocarían los botones para
acceso rápido a funciones secundarias de la tarea (La unica accion
principal, claramente definida por el título de la tarea se ejecuta con
el botón de Ok de la Barra de Herramientas de pyPYME... o presionando
su tecla de acceso rápido).<br>
Cabe recordar que al activar una tarea, ésta podría agregar elementos
propios al menú principal, los cuales serán automáticamente retirados
por la interfaz gráfica al desacrivarla. En estos elementos de menú se
pueden repetir funcionalidades de las funciones de la barra de
herramienta y agragar otras que por espacio no entran.<br>
<br>
Debajo de la Barra de Herramienta de la Tarea se encuentra la página de
la tarea. Propongo diseñar las vistas de forma de pensarlas en páginas
como si fueran páginas web (basicamente porque los usuarios están
acostumbrados a este tipo de visualización y enfoca a los programadores
a pensar en la cantidad de información mostrada y ahorrar ancho de
banda caso instalar pyPYME en una tipología de n-capas).<br>
<br>
En el ángulo inferior derecho (entre ambas barras de desplazamiento) se
encuentra un ícono que permite visualizar el "Área de Trabajo" a
pantalla completa, escondiendo el título de la Interfaz, el menú
principal, la barra de de herramientas de pyPYME y el Area de
Servicios; solo dejando la Barra de Estado que es donde el sistema
muestra mensajes e interactúa con el usuario a medida que ejecutar la
tarea.<br>
<br>
En la parte Inferior es donde se encuentran las "polémicas" solapas
mostrando otras tareas que el usuario dejó en "suspenso" y que puede
retomar o cerrar.<br>
Suguiero que el administrador pueda, por configuración limitar la
cantidad máxima de tareas en suspenso que un usuario pueda tener
abiertas. Un número de 4 (cuatro), admás de la tarea activa, parece
razonable.<br>
<br>
Espero haber tarsmitido mejor el concepto.<br>
<br>
¿Están de acuerdo?<br>
<br>
C.<br>
</body>
</html>

Re: [pyPYME-Giotto] Interfaz Grafica

[Patricio V. <pat...@mu...>]

Cesar Pablo Verdes wrote:
>>
> Totalmente de acuerdo con tu cr=C3=ADtica hacia las MDI y a la necesida=
d de=20
> presentarle al usuario un bloque de informaci=C3=B3n por vez. Creo que =
las=20
> interfaces MDI son una porquer=C3=ADa y en la pr=C3=A1ctica nadie usa m=
=C3=A1s de un=20
> documento maximizado por vez.
>=20
> Yo me refiero a otra funcionalidad, a la funcionalidad de multi-solapas=
=20
> (disculpa por no saber si tiene un nombre m=C3=A1s t=C3=A9cnico). Es un=
a=20
> funcionalidad similar a cuando ten=C3=A9s varios documentos abiertos en=
=20
> Eclipse, varias hojas en un libro de Excel, o varias p=C3=A1ginas web a=
l=20
> navegar con Mozilla.
>=20
ahhh!!! eso, claro que si, me parce perfecto, al menos como se maneja en=20
eclipse, firefox, en quanta, y en otros Ides,, apoyo totalmente ese model=
o


> Personalmente veo contraproducente abrir varias ventanas SDI a la vez=20
> (he llegado a ver usuarios con varias ventanas SDI abiertas de la misma=
=20
> tarea sin darse cuenta, inclusive bloqueandose recursos ellos mismos=20
> entre ventanas). Por eso prefiero la idea de una cantidad limitada de=20
> solapas (4 =C3=B3 5) que le permita tener 1 (una y solo una) tarea acti=
va y 3=20
> =C3=B3 4 tareas en suspenso en otras solapas.
>=20
Aqui la soluci=C3=B3n seria los singletones creo... claro, como en eclips=
e al=20
querer abrir un recurso abierto no te lo vuelve a abrir sino te lleva al=20
que ya se encuentra funcional

> =C2=BFLogr=C3=A9 explicar la diferencia con el concepto de MDI? =C2=BFC=
ompartes los=20
> comentarios? =C2=BFTienes alguna sugerencia para mejorar el concepto?
>=20
> C.
Me permito opinar, yo lo veo muy bien, bastante prometedor...

Adelante

Patricio

--=20
patoValarezo
Linux User#155545
"El que no llora, no mama. "

Re: [pyPYME-Giotto] Interfaz Grafica

[Jose <coo...@py...>]

El mi=E9, 13-07-2005 a las 04:50, Cesar Pablo Verdes escribi=F3:
> Jose wrote:
>=20
> >Ya que puede considerarse como una mejora y no una funcionalidad "base=
",
> >puede estudiarse para una versi=F3n post-1.0.
> > =20
> >
> Entiendo.
>=20
> =BFSugeris que postergue el trabajo de an=E1lisis y codificaci=F3n de l=
a=20
> interfaz propuesta para m=E1s adelante? =BFNo ser=EDa posible continuar=
 de=20
> alguna forma?

No.

No me refer=EDa a aplazar el estudio que est=E1s realizando (que parece
bastante bueno y detallado) sino a aplazar, para una versi=F3n posterior,
la implementaci=F3n de un sistema de gu=EDas. Como puedes observar me
refiero a la implementaci=F3n y no al an=E1lisis o al dise=F1o que s=ED m=
e
parece =FAtil realizarlo cuanto antes.

Saludos,
Jose

Re: [pyPYME-Giotto] Ancho de banda limitado

[Cesar P. V. <ces...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Patricio Valarezo wrote:
<blockquote cite="mid...@mu..."
 type="cite">Me olvidaba!, ya has pensado en alguna soluci&oacute;n para la
interface en redes con anchos de banda limitados ?, podr&iacute;amos adaptar
la misma interface o ser&aacute; necesario crear alguna alternativa mas
liviana (si es que existe) o en "modo texto",&nbsp; no tengo experiencia con
esto, no se que tan efectiva puede resultar la versi&oacute;n XMLRPC de pyPyme
para estos ambientes. En un futuro me gustar&iacute;a a mi trabajar en alguna
versi&oacute;n del POS para dispositivos de mano.
  <br>
</blockquote>
&iexcl;Que buena pregunta Patricio! <span class="moz-smiley-s3"><span> ;-) </span></span><br>
<br>
Si bien no he aun profundizado el an&aacute;lisis del c&oacute;digo actual, creo que
si la interfaz gr&aacute;fica tiene localmente acceso a las vistas y
controladores no habr&iacute;a problemas de lograr una buena eficiencia de
llamadas XMLRPC a otros componentes.<br>
<br>
Lo coloqu&eacute; como Historia &Eacute;pica porque creo que es un tema muy
importante al momento de dise&ntilde;ar las vistas y sus funcionalidades. <br>
<br>
Por ejemplo, si bien puede ser muy comodo para el usuario desplegar la
lista completa de clientes para elegir uno de ellos (enfoque comun en
aplicaciones con arquitecturas de una y dos capas) puede ser
terriblemente ineficiente para n-capas con ancho de banda limitado.<br>
Una soluci&oacute;n (que por ejemplo implementa SAP) es manejar c&oacute;digos para
ubicar elementos (clientes, facturas, materiales, etc), y si el usuario
no sabe el c&oacute;digo o no lo recuerda y necesita ayuda para buscar un
elemento en particular, presentar primero una ventana de filtro de
b&uacute;squeda (SAP las llama match-codes) antes de mostrar ningun set de
elementos, y siempre que fuera posible limitar la cantidad de elementos
a un valor m&aacute;ximo (ejemplo 100 o 1000) a devolver a la interfaz
gr&aacute;fica, avisando al usuario que se devuelve una cantidad limitada del
conjunto resultante a su b&uacute;squeda.<br>
<br>
Si usamos el XMLRPC para ejecutar funciones y solicitar acotadas listas
de elementos no veo que sea inconveniente para la eficiencia al
utilizar bajos anchos de banda.<br>
<br>
<i>Insisto</i>, es un tema de enfoque de la aplicaci&oacute;n desde su
comienzo y personalmente creo que vale la pena tenerlo en cuenta. He
visto aplicaciones con estructura de dos capas cuya performance empeora
notoriamente cuando crece la cantidad de informaci&oacute;n almacenada por un
mal dise&ntilde;o de vistas y controladores. Una pregunta posible ser&iacute;a &iquest;Como
funcionar&iacute;a este formulario si fuera una p&aacute;gina web?<br>
<br>
Por otro lado, mi opinion es que las versiones para interfaces en modo
texto deben tener vistas y controladores espec&iacute;ficos, considero muy
complejo (por no decir ut&oacute;pico) tratar de unicicar el dise&ntilde;o, porque no
quedar&iacute;a otra alternativa que limitar el potencial de la interfaz
gr&aacute;fica.<br>
<br>
&Eacute;ste es un tema importante, tiene muchos enfoques y creo que tendremos
que estudiarlo m&aacute;s profundamente cuando llegue su momento, sin dejar de
lado el objetivo al realizar la codificaci&oacute;n actual. <br>
<br>
&iquest;Estas de acuerdo?<br>
<br>
C.<br>
</body>
</html>


	

	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 

Re: [pyPYME-Giotto] Interfaz Grafica

[Cesar P. V. <ces...@ya...>]

Jose wrote:

>Ya que puede considerarse como una mejora y no una funcionalidad "base",
>puede estudiarse para una versión post-1.0.
>  
>
Entiendo.

¿Sugeris que postergue el trabajo de análisis y codificación de la 
interfaz propuesta para más adelante? ¿No sería posible continuar de 
alguna forma?

Lamentaría suspender este desarrollo. Deseo profundamente participar en 
el proyecto pyPYME y me interesan mucho (y necesito) sus consejos, 
preguntas y críticas.

¿Que opinás?

C.


	

	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 

Re: [pyPYME-Giotto] Interfaz Grafica

[Cesar P. V. <ces...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jose wrote:<br>
<blockquote cite="mid...@de..."
 type="cite">
  <blockquote type="cite">
    <pre wrap="">      * Los usuarios podran mantener abiertas en la misma “área de
        trabajo” en forma simultaneamea varias tareas en distintos
        estados de ejecución.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No.

Eso es lo que hacían los diseños MDI que están siendo sustituidos (tanto
por Microsoft como por otros grandes fabricantes) por un diseño SDI que
incluye navegación e integración de contenidos.

Hace tiempo leí unos estudios (lo siento, no recuerdo cuáles) en los que
se concluía, dada la limitada capacidad visual y de memorización del ser
humano, que era mejor presentar un único bloque informativo (p.e. la
ficha de un cliente, una factura, un ingreso en caja, etc) que varios.

Supongo que en alguno de estos estudios de interfaz hombre-máquina es en
lo que se han basado los expertos de Microsoft y demás.
  </pre>
</blockquote>
Totalmente de acuerdo con tu crítica hacia las MDI y a la necesidad de
presentarle al usuario un bloque de información por vez. Creo que las
interfaces MDI son una porquería y en la práctica nadie usa más de un
documento maximizado por vez.<br>
<br>
Yo me refiero a otra funcionalidad, a la funcionalidad de multi-solapas
(disculpa por no saber si tiene un nombre más técnico). Es una
funcionalidad similar a cuando tenés varios documentos abiertos en
Eclipse, varias hojas en un libro de Excel, o varias páginas web al
navegar con Mozilla.<br>
<br>
La idea surge de la necesidad que tienen los usuarios de consultar
cierta información o realizar una tarea suspendiendo la que están
haciendo para luego continuarla. Por ejemplo... imagina un usuario que
está cargando un documento de despacho y de pronto recibe el llamado de
un cliente que desea consultar un dato sobre su cuenta corriente.<br>
<br>
Personalmente veo contraproducente abrir varias ventanas SDI a la vez
(he llegado a ver usuarios con varias ventanas SDI abiertas de la misma
tarea sin darse cuenta, inclusive bloqueandose recursos ellos mismos
entre ventanas). Por eso prefiero la idea de una cantidad limitada de
solapas (4 ó 5) que le permita tener 1 (una y solo una) tarea activa y
3 ó 4 tareas en suspenso en otras solapas.<br>
<br>
¿Logré explicar la diferencia con el concepto de MDI? ¿Compartes los
comentarios? ¿Tienes alguna sugerencia para mejorar el concepto?<br>
<br>
C.<br>
</body>
</html>


	

	
		
___________________________________________________________ 
1GB gratis, Antivirus y Antispam 
Correo Yahoo!, el mejor correo web del mundo 
http://correo.yahoo.com.ar 

Re: [pyPYME-Giotto] Ideas concretas

[Cesar P. V. <ces...@ya...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Abajo mis comentarios<br>
<br>
Marcelo G Ametller wrote:
<blockquote cite="mid...@ma..."
 type="cite">
  <pre wrap="">Muy bueno tu analisis, aunque no alcanzo a entender que iria en el
area de servicios... esto es "a priori", con mas tiempo lo analizo
mejor y te digo.

Algun ejemplo desplegado...</pre>
</blockquote>
Marcelo, ten&eacute;s raz&oacute;n, no est&aacute; claro. Fue lo &uacute;ltimo que escrib&iacute; ayer,
estaba canzado y lo liber&eacute; muy en bruto <span class="moz-smiley-s2"><span>
:-( </span></span><br>
<br>
El <i><b>&Aacute;rea de Servicios</b></i> servir&iacute;a para ubicar todo aquello
que no es una vista de una tarea funcional de pyPYME pero que ayuda al
usuario a encontrar la tarea o elemento con el que desea trabajar, as&iacute;
como tambi&eacute;n interactuar con sus compa&ntilde;eros de trabajo.<br>
<br>
En la parte superior se encuentran iconos. Al elegir uno de ellos la
parte de abajo (la verde lisa) desarrolla la selecci&oacute;n del usuario.<br>
<br>
Vemos los iconos propuestos:<br>
<ul>
  <li><i>&Aacute;rbol de tareas de los m&oacute;dulos instalados:</i></li>
</ul>
<blockquote>Permite buscar una tarea entre las que tiene posibles
ejecutar el usuario logoneado seg&uacute;n sus permisos.<br>
En algunos sistemas como SAP existe la posibilidad de que el
administrador defina un men&uacute; especial seg&uacute;n el perfil o usuario. Si no
lo hace se muestra todo el &aacute;rbol de opciones instaladas, pero no se le
permite ejecutarla tras ser seleccionada con un mensaje de error de
permiso de acceso.<br>
</blockquote>
<blockquote><img alt="" src="cid:par...@ya..."
 height="512" width="380"><br>
</blockquote>
<blockquote>Detro del &Aacute;rea de Servicio se despliegan los campos para
realizar la b&uacute;squeda por descripci&oacute;n de la tarea. El campo de b&uacute;squda
es un combo desplegable donde se muestran las &uacute;ltimas b&uacute;squdas del
usuario.<br>
Al realizar la b&uacute;squeda (tipo google simplificado con palabras claves,
frases, palabras obligatorias, etc) se abren las ramas que tengan
tareas que cumplan la condici&oacute;n de b&uacute;squeda y al presionar el bot&oacute;n de
largavista el sistema ir&aacute; posando la seleccion sobre las tareas en
forma c&iacute;clica.<br>
  <br>
Debajo del &aacute;rbol de tareas (en esta imagen ejemplificado con un arbol
de
directorios y un archivo) se encuentra una barra herramientas
espec&iacute;fica con los siguientes &iacute;conos de izquierda a derecha:<br>
  <ol>
    <li>Colapsar la rama del arbol seleccionada</li>
    <li>Colapsar todo el arbol</li>
    <li>Expandir la rama del arbol seleccionada</li>
    <li>Expandir todo el arbol</li>
    <li>Comenzar la tarea en el &Aacute;rea de trabajo, cancelando la tarea
que est&eacute; activa en ese momento (previa consulta con un d&iacute;alogo de
confirmaci&oacute;n de ser necesario)</li>
    <li>Comenzar la tarea en una nueva solapa dentro del &Aacute;rea de
trabajo de la misma ventana de la interfaz gr&aacute;fica</li>
    <li>Abrir una nueva ventana (con todas sus &aacute;reas) y comenzar la
tarea seleccionada en el &Aacute;rea de Trabajo<br>
    </li>
  </ol>
</blockquote>
<ul>
  <li><i>Tareas relacionadas con la tarea actual</i>:</li>
</ul>
<blockquote>Para cada tarea los programadores pueden indicar otras
tareas asociadas que usualmente los usuarios utilizan simultaneamente o
tras completar la tarea corriente.<br>
Por ejemplo, si el usuario est&aacute; cargando una factura de venta, puede
necesitar acceder a la cuenta corriente del cliente, los datos del
mismo, alg&uacute;n detalle de un art&iacute;culo, etc. Para evitar que el usuario
tenga que buscar la tarea entre todas las posibles en el arbol del
sistema, al utilizar este servicio se muestra una serie de "links"
&uacute;tiles a otras tareas.<br>
Una visi&oacute;n posible podr&iacute;a ser:<br>
&nbsp;&nbsp;&nbsp; TBD<br>
  <br>
  <i><b>Nota:</b></i> Al profundizar el an&aacute;lisis he eliminado la opcion
"Elementos relacionados con la tarea o elemento actual" ya que me pare
innecesario. A la larga siempre se hacen una tarea sobre los elementos.<br>
</blockquote>
<ul>
  <li><i>Links a las tareas preseleccionadas por el usuario:</i></li>
</ul>
<blockquote>El concepto de este servicio de la interfaz gr&aacute;fica es que
el usuario se arme su propio conjunto de links a tareas de su
preferencia... pudiendo organizarlas en forma de &aacute;rbol, si es que lo
desea.<br>
Una visi&oacute;n posible podr&iacute;a ser:<br>
&nbsp;&nbsp;&nbsp; TBD<br>
  <br>
</blockquote>
<ul>
  <li><i>Enviar mensajes a otros usuarios conectados y ver los mensajes
recibidos por otros usuarios:</i></li>
</ul>
<blockquote>Este servicio de la interfaz gr&aacute;fica prestar&iacute;a servicios
similares al MSN, aunque acotados a mensajes de texto e im&aacute;genes de
pantallas de la tarea activa en el &Aacute;rea de Trabajo y solamente entre
usuarios del sistema.<br>
Esta funcionalidad surge de que hay empresas que no permiten sistemas
p&uacute;blicos de mensajer&iacute;a, pero es una herramienta muy &uacute;til para uso
interno.<br>
Adisionalmente facilitar&iacute;a el soporte remoto por parte de usuarios
expertos.<br>
El usuario podr&iacute;a elegir enter buscar un usuario en el arbol
organizacional de toda la empresa, por orden alfab&eacute;tico, o armar su
propio grupo de usuarios pudiendo organizarlos en forma de &aacute;rbol, si es
que lo desea.<br>
Una visi&oacute;n posible podr&iacute;a ser:<br>
&nbsp;&nbsp;&nbsp; TBD</blockquote>
<br>
Espero haber sido m&aacute;s claro y quedo abierto a nuevos comentarios,
cr&iacute;ticas y sugerencias.<br>
<br>
C.<br>
</body>
</html>

Re: [pyPYME-Giotto] Ideas concretas

[Patricio V. <pat...@mu...>]

Cesar Pablo Verdes wrote:
> Gente

> Ma=F1ana contin=FAo.
>=20
> Espero sus comentarios. :-)
>=20
> C.

Me olvidaba!, ya has pensado en alguna soluci=F3n para la interface en=20
redes con anchos de banda limitados ?, podr=EDamos adaptar la misma=20
interface o ser=E1 necesario crear alguna alternativa mas liviana (si es=20
que existe) o en "modo texto",  no tengo experiencia con esto, no se que=20
tan efectiva puede resultar la versi=F3n XMLRPC de pyPyme para estos=20
ambientes. En un futuro me gustar=EDa a mi trabajar en alguna versi=F3n d=
el=20
POS para dispositivos de mano.

bueno, te dejo estas inquietudes.

saludos.

Patricio

--=20
patoValarezo
Linux User#155545
"Muchas vacas en un sel, est=E1n mal y parecen bien. "

Re: [pyPYME-Giotto] Ideas concretas

[Patricio V. <pat...@mu...>]

Cesar Pablo Verdes wrote:
> Gente
>=20
> Continuo con mis ideas sugerencias de la interfaz de usuario:
>=20
> La ventana principal se podr=EDa dividir en las siguientes =E1reas:
>=20
>=20
>=20
> Donde:
>=20
>     * La */Barra de Titulo/* ser=E1 el t=EDtulo de la ventana del siste=
ma
>       operativo. Como t=EDtulo de la ventana se colocar=E1 "pyPYME -
>       Bienvenido Cesar Verdes", donde "Cesar Verdes" es el nombre largo
>       del usuario logoeado.
>     * El */Men=FA Principal/* ser=E1 el men=FA del sistema pyPYME, con
>       funcionalidades comunes a cualquier tarea, y el men=FA se modific=
a
>       din=E1micamente al activar una vista en el "Area de Trabajo" la c=
ual
>       puede agregar sus propias opciones de Menu y Submenues.
>     * La Barra de Herramienta de pyPYME tendr=E1 las opciones comunes a=
 la
>       navegaci=F3n del sistema y funcionalidades intr=EDnsicas a la UI =
o
>       comunes a muchas tareas.
>=20
>     Propongo la siguiente /Barra de Herramientas de pyPYME/:
>=20
>=20
>     Donde el significado de los =EDconos de izquierda a deracha son:
>=20
>        1. Terminar la Tarea
>        2. Cancelar la Tarea
>        3. Ir a la pantalla anterior caso la tarea tenga varias ventanas=
,
>           o volver a la pantalla de donde se llam=F3 la tarea.
>        4. Grabar todos los datos registrados en la tarea hasta el
>           momento (sin darla por terminada)
>        5. Buscar un tecto en la vista actual
>        6. Imprimir (caso est=E9 habilitada la funcionalidad para la vis=
ta
>           activa)
>        7. Cortar
>        8. Copiar
>        9. Pegar
>       10. Ir a la pantalla principal del usuario (su "home" con las
>           tareas usadas recientemente, sus tareas preferidas, los
>           elementos sobre los cuales suele trajar y otra informaci=F3n =
que
>           le pueda ser de utilidad)
>       11. Mostrar u ocultar el =C1rea de Servicios a fin de ganar m=E1s
>           espacio para el =C1rea de Trabajo
>       12. Ayuda de como realizar la tarea de la vista activa (es una
>           ayuda contextual que se despliega en el =C1rea de Trabajo,
>           mostrando en el =C1rea de Servicios ayudas relacionadas.
>       13. Campo donde el usuario experto puede tipear el c=F3digo de un=
a
>           tarea para abrirla directamente en el "=C1rea de Trabajo" (no
>           requiere buscarla en ning=FAn men=FA ni arbol de tareas). Est=
e
>           campo es un campo desplegable donde se muestran las tareas
>           ordenando primero las tareas llamadas recientemente por ese
>           usuario.
>       14. Bloquea la Interfaz Gr=E1fica para que ning=FAn otro usuario =
pueda
>           realizar cambios sin cerrar =E1rea ni tarea. Esta opci=F3n pu=
ede
>           ser =FAtil cuando el usuario desea levantarse de su escritori=
o
>           por unos minutos.
>       15. Deslogonea al usuario actual, volviendo a la pantalla de logi=
n
>           del sistema.
>=20
>     * En el /*=C1rea de Servicios*/ se despliegan opciones =FAtiles de
>       b=FAsquda de tareas y elementos sobre los cuales el usuario desea
>       realizar alguna operaci=F3n.
>=20
>     Propongo la siguiente /=C1rea de Servicios/:
>=20
>=20
>     Donde en la parte superior se encuentra una serie de =EDconos de
>     acceso a los servicios.
>     Entre los servicios propuestos incluyo de izquierda a derecha:
>=20
>        1. =C1rbol de tareas de los m=F3dulos instalados
>        2. Tareas relacionadas con la tarea o elemento actual
>        3. Elementos relacionados con la tarea o elemento actual
>        4. Links a las tareas preseleccionadas por el usuario
>        5. Enviar mensajes a otros usuarios conectados y ver los mensaje=
s
>           recibidos por otros usuarios.
>=20
>     * El /*=C1rea de Trabajo*/ es donde se despliegan las vistas de los
>       componentes. TBD
>     * La /*Barra de Estado*/ es usada principalmente para que pyPYME
>       envie mensajes al usuario en respuesta a sus acciones (mensajes,
>       advertencias, errores, indicaci=F3n de tarea en proceso, etc) y o=
tra
>       informaci=F3n =FAtil como la hora y el d=EDa con posibilidad de
>       desplegar un calendario. TBD
>=20
> /*Nota:*/ Los =EDconos son sacados de la base de =EDconos de SAP, luego=
=20
> podemos solicitar la ayuda de un dise=F1ador gr=E1fico para darle una=20
> personalidad =FAnica a pyPYME.
>=20
> Ma=F1ana contin=FAo.
>=20
> Espero sus comentarios. :-)
>=20
> C.

Lo veo muy bien, solo un comentario: Hace algunos meses decidimos no=20
usar un contenedor MDI para la interface, no se si tu dise=F1o est=E1=20
contemplando contenedores MDI, de la forma en que Jos=E9 ha programado lo=
s=20
componentes creo que si podr=EDan adaptarse a este esquema "monoformulari=
o",

saludos

--=20
patoValarezo
Linux User#155545
"Muchas vacas en un sel, est=E1n mal y parecen bien. "

Re: [pyPYME-Giotto] Interfaz Grafica

[Jose <coo...@py...>]

El lun, 11-07-2005 a las 01:13, Cesar Pablo Verdes escribi=C3=B3:
> He tratado de respetar los estandares de documentaci=C3=B3n del proyect=
o.
> Les alcanzo el primer borrador de los Roles y las Historias Epicas.
> Comenc=C3=A9 a redactar el documento como si se tratara de un m=C3=B3du=
lo nuevo.
> A medida que desarrollaba el documento observ=C3=A9 que ten=C3=ADa much=
as cosas
> en com=C3=BAn con el componente "Centro de Control", aunque con mayor
> alcance.
>=20
> Les ruego que no se asusten por la aparente ambici=C3=B3n de alcance y
> complejidad del m=C3=B3dulo planteada en este documento. Son ideas que =
creo
> convenientes implementar en la interfaz gr=C3=A1fica de pyPYME basadas =
en
> conceptos de la SAPGui, la teor=C3=ADa Inductive User Ineterfase de
> Microsoft, conceptos e ideas de otros productos como Compiere,
> FacturaLUX, TinyERP, Eclipse y Groove; las teor=C3=ADas de UIs basadas =
en
> patrones y task oriented UIs, as=C3=AD como tambi=C3=A9n de mis necesid=
ades como
> usuario de ERP.

Una buena colecci=C3=B3n de referencias 8-) .

> Desear=C3=ADa que analicen cada punto en forma objetiva sin pensar en e=
l
> c=C3=B3digo existente o la posible complejidad que su implementaci=C3=B3=
n podr=C3=ADa
> implicar. Les pido que critiquen este documento con una visi=C3=B3n de
> "Nice to Have".
>=20
> Tras analizar sus comentarios, y en caso que Uds. no observen ning=C3=BA=
n
> inconveniente importante proceder=C3=A9 al an=C3=A1lisis de "Composici=C3=
=B3n" y la
> documentaci=C3=B3n de cada uno de los componente (Historias de usuario =
y
> Tests de aceptacion)
>=20
> Espero ansiosamente vuestros comentarios. :-)=20
>=20
> C.
>=20
>=20
> Encargado el organizar el di=C3=A1logo entre el usuario y los component=
es a
> traves de una interfaz gr=C3=A1fica estandarizada y la administraci=C3=B3=
n de
> las vistas y controladores de los componentes de los dem=C3=A1s m=C3=B3=
dulos.
> Roles
>=20
> Usuario=20
>         Cualquier persona que hace uso de esta aplicaci=C3=B3n,
>         independientemente del perfil de seguridad bajo el que opere.=20
>         Usuario especializado=20
>         Usuario que utiliza frecuentemente un n=C3=BAmero de acotado de
>         funcionalidades del sistema las cuales conoce en detalle y
>         opera muy r=C3=A1pidamente.=20
>         Usuario espor=C3=A1dico=20
>         Usuario que peri=C3=B3dicamente debe realizar alguna tarea en e=
l
>         sistema al cual no oper=C3=A1ndolo con fluidez=20
>         Soporte funcional=20
>         Usuario especializado en determinadas funcionalidades del
>         sistema cuya funci=C3=B3n es ayudar a los otros usuarios a util=
izar
>         el sistema.=20
> Administrador=20
>         Usuario que act=C3=BAa bajo un perfil de seguridad especial que=
 le
>         permite acceder, usar y configurar cualquiera de los elementos
>         de la aplicaci=C3=B3n=20
>         Programador =20
>         Cualquier persona que programa nuevas vistas y controladores.=20
> Dise=C3=B1ador=20
>         Cualquier persona que produce im=C3=A1genes y estilos aplicable=
s a
>         los est=C3=A1ndares de la interfaz gr=C3=A1fica.

Ok

> Historias =C3=A9picas
>       * Los usuarios podr=C3=A1n =E2=80=9Cnavegar=E2=80=9D por el siste=
ma accediendo a
>         distintos niveles de detalle de la informaci=C3=B3n, entidades =
y
>         tareas relacionadas a la tarea que est=C3=A1n ejecutando o dese=
a
>         ejecutar.

Ok

>       * Los usuarios especializados podr=C3=A1n acceder y ejecutar
>         r=C3=A1pidamente cualquier tarea.

Ok

>       * Los usuarios espor=C3=A1dicos ser=C3=A1n guiados por el sistema=
 a fin de
>         localizar y completar las tareas que necesiten ejecutar.

Ok.

Ya que puede considerarse como una mejora y no una funcionalidad "base",
puede estudiarse para una versi=C3=B3n post-1.0.

>       * Los usuarios podr=C3=A1n operar el sistema con tiempos razonabl=
es
>         de respuesta conectados a la red con anchos de banda limitados
>         como los que presentan las conexiones dial-up.

Ok

>       * La interfaz gr=C3=A1fica ser=C3=A1 autocontenida en una sola ve=
ntana
>         segmentada en distintas =C3=A1reas funcionales, aunque los usua=
rios
>         podr=C3=A1n abrir m=C3=A1s de una instancia de la interfaz en c=
aso que
>         lo desearan.

Ok

>       * Las vistas se desplegar=C3=A1n en una =C3=A1rea de la interfaz =
gr=C3=A1fica
>         llamada =E2=80=9C=C3=A1rea de trabajo=E2=80=9D.

Ok

>       * Los usuarios podran mantener abiertas en la misma =E2=80=9C=C3=A1=
rea de
>         trabajo=E2=80=9D en forma simultaneamea varias tareas en distin=
tos
>         estados de ejecuci=C3=B3n.

No.

Eso es lo que hac=C3=ADan los dise=C3=B1os MDI que est=C3=A1n siendo sust=
ituidos (tanto
por Microsoft como por otros grandes fabricantes) por un dise=C3=B1o SDI =
que
incluye navegaci=C3=B3n e integraci=C3=B3n de contenidos.

Hace tiempo le=C3=AD unos estudios (lo siento, no recuerdo cu=C3=A1les) e=
n los que
se conclu=C3=ADa, dada la limitada capacidad visual y de memorizaci=C3=B3=
n del ser
humano, que era mejor presentar un =C3=BAnico bloque informativo (p.e. la
ficha de un cliente, una factura, un ingreso en caja, etc) que varios.

Supongo que en alguno de estos estudios de interfaz hombre-m=C3=A1quina e=
s en
lo que se han basado los expertos de Microsoft y dem=C3=A1s.

>       * Ser=C3=A1 simple para los usuarios identificar la tarea que est=
=C3=A1n
>         ejecutando en cada momento, podr=C3=A1n comprender facilmente
>         cuales son los pasos necesarios para concluirla, como
>         cancelarla y como comenzar una tarea nueva.

Ok

>       * Los usuarios encontrar=C3=A1n en las vistas de los componentes
>         todas las funcionalidades necesarias para ejecutar una y solo
>         una tarea a la vez, la cual ser=C3=A1 claramente especificada p=
or
>         su t=C3=ADtulo.

Ok

>       * La cantidad de widgets utilizables por los programadores para
>         crear las vistas ser=C3=A1 limitada y estandarizada tanto en
>         funcionalidad como en est=C3=A9tica por el documento de =E2=80=9C=
Guia de
>         Estilo=E2=80=9D.

Ok

>       * Los programadores contar=C3=A1n con patrones para facilitar la
>         implementaci=C3=B3n de las vistas de los componentes de la
>         aplicaci=C3=B3n.

Ok

>       * La programadores contar=C3=A1n con un stock acotado de im=C3=A1=
genes e
>         iconos para dise=C3=B1ar las vistas. Los dise=C3=B1adores podr=C3=
=A1n definir
>         y agregar al stock del sistema nuevas im=C3=A1genes e =C3=ADcon=
os a
>         medida que los programadores lo requieran.

Ok

>       * Los usuarios podr=C3=A1n acceder a la cola de impresi=C3=B3n de=
l sistema
>         y visualizar en el =C3=A1rea de trabajo los documentos y report=
es
>         que se haya solicitado antes de ser impresos, o eliminarlos de
>         la cola de impresi=C3=B3n sin imprimirlo.

Ok.

Por desgracia esta funcionalidad a=C3=BAn queda lejana en el tiempo. No e=
s
que no la considere importante (=C2=A1 de hecho es imprescindible !) sino=
 que
la tecnolog=C3=ADa de la que disponemos no est=C3=A1, que digamos, muy el=
aborada.
Este es otro apartado que exige un cuidadoso estudio.

>       * La interfaz gr=C3=A1fica facilitar=C3=A1 el trabajo en equipo d=
e los
>         usuarios y el soporte remoto.

Ok

Buen trabajo.

Saludos,
Jose

Re: [pyPYME-Giotto] [CHARON] Formularios-lista

[Jose <coo...@py...>]

El s=E1b, 09-07-2005 a las 18:31, Patricio Valarezo escribi=F3:
> Me refiero a tener que pegarse el camello(trabajo) de dar soporte=20
> multilenguaje, ahora averiguar como est=E1 el soporte i18n en pyqt creo=
=20
> que si se deber=EDa hacer, voy a averiguar un poco de esto y les coment=
o

Quedo a la espera, ya que es un tema muy importante.

Jose

[pyPYME-Giotto] [GIOTTO] i18n

[Jose <coo...@py...>]

El s=E1b, 09-07-2005 a las 18:09, Patricio Valarezo escribi=F3:
> Jose wrote:
> > Tambi=E9n ten en cuenta que el soporte i18n bajo PyQt a=FAn no lo he
> > analizado y, adem=E1s, creo recorder que en alg=FAn caso tuve que hac=
er "un
> > apa=F1o" creando m=E9todos __tr y __trUtf8 para que el c=F3digo de al=
guna
> > clase pudiera compilar. =BFAlguno se anima a realizar este estudio?
> >=20
> mmm... pienso que deber=EDa ir junto con la documentaci=F3n de usuario =
de la=20
> primera versi=F3n, me parece demasiado trabajo al menos para estas etap=
as=20
> del proyecto y en cierto sentido podr=EDa ser en vano, tengo la leve id=
ea=20
> de que python se lleva bien con GNU gettext y no creo que ser=E1 un=20
> problema en el futuro... Por otro lado el soporte utf8 lo veo inmaduro=20
> en algunos lados, yo no he podido dar soporte completo a mi gentoo noto=
=20
> que algunas aplicaciones se resbalan demasiado con esto (incluso eclips=
e)

El tema del soporte i18n presenta 2 "ejes":

	- por un lado requiere trabajo (bastante trabajo). Las aplicaciones Qt
utilizan su propio sistema mediante "Qt Linguist", los m=E9todos __tr y e=
l
soporte de la libreria qt. No s=E9 si es suficiente, si nos obligar=EDa a
trabajar con gettext, o si deber=EDamos utilizar exclusivamente gettext

	- por otro lado, ya que =E9ste es un proyecto multi-nacional, deber=EDam=
os
dar este tipo de soporte. En este caso y como paso previo, habr=EDa que
hacer un estudio y una bater=EDa de pruebas que nos permitiese saber c=F3=
mo
a=F1adir este soporte

Re: [pyPYME-Giotto] Ideas concretas

[Marcelo G A. <mam...@gm...>]

On 7/11/05, Cesar Pablo Verdes <ces...@ya...> wrote:
> Gente=20
>=20
> Continuo con mis ideas sugerencias de la interfaz de usuario:
>=20
> La ventana principal se podr=EDa dividir en las siguientes =E1reas:
>=20
>=20
>=20
> Donde:
>=20
> La Barra de Titulo ser=E1 el t=EDtulo de la ventana del sistema operativo=
. Como
> t=EDtulo de la ventana se colocar=E1 "pyPYME - Bienvenido Cesar Verdes", =
donde
> "Cesar Verdes" es el nombre largo del usuario logoeado.=20
> El Men=FA Principal ser=E1 el men=FA del sistema pyPYME, con funcionalida=
des
> comunes a cualquier tarea, y el men=FA se modifica din=E1micamente al act=
ivar
> una vista en el "Area de Trabajo" la cual puede agregar sus propias opcio=
nes
> de Menu y Submenues.=20
> La Barra de Herramienta de pyPYME tendr=E1 las opciones comunes a la
> navegaci=F3n del sistema y funcionalidades intr=EDnsicas a la UI o comune=
s a
> muchas tareas.=20
> Propongo la siguiente Barra de Herramientas de pyPYME:
>=20
>=20
> Donde el significado de los =EDconos de izquierda a deracha son:
>=20
> Terminar la Tarea=20
> Cancelar la Tarea=20
> Ir a la pantalla anterior caso la tarea tenga varias ventanas, o volver a=
 la
> pantalla de donde se llam=F3 la tarea.=20
> Grabar todos los datos registrados en la tarea hasta el momento (sin darl=
a
> por terminada)=20
> Buscar un tecto en la vista actual=20
> Imprimir (caso est=E9 habilitada la funcionalidad para la vista activa)=
=20
> Cortar=20
> Copiar=20
> Pegar=20
> Ir a la pantalla principal del usuario (su "home" con las tareas usadas
> recientemente, sus tareas preferidas, los elementos sobre los cuales suel=
e
> trajar y otra informaci=F3n que le pueda ser de utilidad)=20
> Mostrar u ocultar el =C1rea de Servicios a fin de ganar m=E1s espacio par=
a el
> =C1rea de Trabajo=20
> Ayuda de como realizar la tarea de la vista activa (es una ayuda contextu=
al
> que se despliega en el =C1rea de Trabajo, mostrando en el =C1rea de Servi=
cios
> ayudas relacionadas.
> Campo donde el usuario experto puede tipear el c=F3digo de una tarea para
> abrirla directamente en el "=C1rea de Trabajo" (no requiere buscarla en n=
ing=FAn
> men=FA ni arbol de tareas). Este campo es un campo desplegable donde se
> muestran las tareas ordenando primero las tareas llamadas recientemente p=
or
> ese usuario.=20
> Bloquea la Interfaz Gr=E1fica para que ning=FAn otro usuario pueda realiz=
ar
> cambios sin cerrar =E1rea ni tarea. Esta opci=F3n puede ser =FAtil cuando=
 el
> usuario desea levantarse de su escritorio por unos minutos.=20
> Deslogonea al usuario actual, volviendo a la pantalla de login del sistem=
a.=20
> En el =C1rea de Servicios se despliegan opciones =FAtiles de b=FAsquda de=
 tareas y
> elementos sobre los cuales el usuario desea realizar alguna operaci=F3n.=
=20
> Propongo la siguiente =C1rea de Servicios:
>=20
>=20
> Donde en la parte superior se encuentra una serie de =EDconos de acceso a=
 los
> servicios.
> Entre los servicios propuestos incluyo de izquierda a derecha:
>=20
> =C1rbol de tareas de los m=F3dulos instalados=20
> Tareas relacionadas con la tarea o elemento actual=20
> Elementos relacionados con la tarea o elemento actual=20
> Links a las tareas preseleccionadas por el usuario=20
> Enviar mensajes a otros usuarios conectados y ver los mensajes recibidos =
por
> otros usuarios.=20
> El =C1rea de Trabajo es donde se despliegan las vistas de los componentes=
. TBD
> La Barra de Estado es usada principalmente para que pyPYME envie mensajes=
 al
> usuario en respuesta a sus acciones (mensajes, advertencias, errores,
> indicaci=F3n de tarea en proceso, etc) y otra informaci=F3n =FAtil como l=
a hora y
> el d=EDa con posibilidad de desplegar un calendario. TBD Nota: Los =EDcon=
os son
> sacados de la base de =EDconos de SAP, luego podemos solicitar la ayuda d=
e un
> dise=F1ador gr=E1fico para darle una personalidad =FAnica a pyPYME.
>=20
> Ma=F1ana contin=FAo.
>=20
> Espero sus comentarios. :-)=20
>=20
> C.
>=20
Muy bueno tu analisis, aunque no alcanzo a entender que iria en el
area de servicios... esto es "a priori", con mas tiempo lo analizo
mejor y te digo.

Algun ejemplo desplegado...=20

--=20
Marcelo Ametller
www.maramsis.com.ar - www.aeroenlace.com.ar
Ubuntu Linux User.