On Saturday, 8 March 2014 12:40:35 UTC+1, Albert Cervera Areny wrote:
2014-03-08 8:19 GMT+01:00 Emma deles...@gmail.com javascript::
I think this is the kind of things Cédric was trying to note which are
going to give bug reports. You cannot safely link labels to fields
Well, in this very particular case (which I don't think is ever going to
be
looked at on a tablet or smart phone since it's part of configuration)
Given that Tryton is mainly a framework it does not matter if this
specific case is going to be used in a tablet or not because
On Friday, 7 March 2014 22:58:56 UTC+1, Albert Cervera Areny wrote:
2014-03-07 19:53 GMT+01:00 Emma deles...@gmail.com javascript::
Hi Guillem,
Well, there have been a few changes since the fork was initiated since
there
was no willingness to make the changes inside the core, why
I think this is the kind of things Cédric was trying to note which are
going to give bug reports. You cannot safely link labels to fields
automatically because Tryton allows much more complex configurations
than label - field structure. You'll maybe end up with something
that renders
Just to add a little feedback: we would be interested in this feature,
whether included or not.
NaN·tic would be interested in this feature too.
Also Zikzakmedia is interested in it.
+1 Me to.
Given the mixed signals received:
- Tryton core team not interested at
OK, I'll set up a codereview tomorow.
Code review is available here: 4081002http://codereview.tryton.org/4081002/
Looks good to me now
On Wednesday, 5 March 2014 10:18:28 UTC+1, Albert Cervera Areny wrote:
2014-03-05 9:09 GMT+01:00 Emma deles...@gmail.com javascript::
OK, I'll set up a codereview tomorow.
Code review is available here: 4081002
Can you re-upload, please. Sometimes
I think this is an interesting hack or proof-of-concept as you say, but
not the approach I would take. Firstly screen resolution is not a reliable
way to determine the nature of a device on its own; my mobile has only as
12cm screen but the resolution is full HD (1920x1080) and so you
Vanilla sao won't be responsive because the GTK client is not
responsive.
If you follow this line of thought, GTK client doesn't work on iOS, then
sao should not work on iOS either?
But I guess that splitting the stylesheet in two parts, one
implementing the default behavior ;
According to me if we can achieve through CSS the exact same behavior
as the GTK client then it is a very nice addition. Emma's work is
probably a good step in this direction. Is it fully doable, I don't
know as I am not a CSS guru.
From what I know, GTK use the two concepts of
From what I know, GTK use the two concepts of expand and fill but in
CSS
we miss the expand concept and it is what is implemented in JS in sao.
I have a fairly good idea of how to implement it during form
generation,
it needs to be implemented and tested thou
Please
Not with the current view.js since it produces table's (which is
probably very fine for tree views, but not for form views concerning
the current matter). Hence this poc to replace form.container
element with div. Now of course, out of the box div's won't look
like the gtk client's
By computing a different colspan makeshift class (col-md-x) during form
creation
That's colspan.
How will be managed the fill and expand.
For example:
form col=4
field name=small xfill=1/
field name=larger xfill=1 xexpand=1/
field name=larger xfill=1 xexpand=1/
Not with the current view.js since it produces table's (which is
probably very fine for tree views, but not for form views concerning
the current matter). Hence this poc to replace form.container
element with div. Now of course, out of the box div's won't look
like the gtk client's
And here is how it works with the PDA mode.
http://www.b2ck.com/~ced/tryton_pda.png
For me, we don't need to be responsible (I mean dynamicaly) because we
generate the HTML in the browser. We just need to implement the same PDA
mode in sao base on the screen size (or whatever is the
But how will they be aligned?
Both behavior could be possible depending on the implementation, once again
it is an fairly good idea, nothing tested yet
|small| larger | larger |small|
|small| larger | larger |small|
| colspan3
base of mixins done by professionnals
I mean css professionnals, I don't mean you guys are not professionals ;-)
So if I understand well what you are saying. If xfill/xexpand work as
intended and the interface renders on larger screens as it renders on
the
gtk client AND renders on smaller screens as it does in pda mode, the
codereview replacing tables by div's would be included in sao?
I
Hi,
I have seen the progress on Sao. Congratulations to everyone.
Although, I've noticed that on small devices, the resize part of the
code, which is called quite often, is taking up a lot of cpu resources.
This could be solved, at least for forms, by switch the resize part of the
code with
The goal of this method is to have an exactly the same behavior between
the tryton and sao.
Well, with this patch, the behavior of sao stays EXACTLY the same (it's
just a poc so far, of course it needs tweaking) as the desktop until you
reach the trigger minimum sizes.
In the poc:
- less
Oops, forgot this part
For small
devices, it is custom user interface/application that must be developped
to manage one specific workflow.
Ok for developping specific screen for small devices (with less field) but
why require a custom application when a specific view would be enough?
So the behavior is not EXACTLY the same.
OK, so I guess this means you are not interested in making sao responsive.
I won't go further then
This patch so far doesn't change any logic on the js side, it just
replaces
a table with div's (colspan implemented but not xexpand nor xfill)
I understand it is not currently implemented because it is a POC but
my question is: can those attributes be implemented?
yes they can
I think there were several people interested in this in last TUB and
you can expect some help from NaN·tic. Not right now, but hopefully in
the near future, so for us a codereview would be great.
OK, I'll set up a codereview tomorow.
I am a bit of a novice in the use of these
I'l try to attend too but November is still far away and I am not certain
of my schedule at the time yet
--
--
tryton@googlegroups.com mailing list
* ashutosh verma [2012-05-28 15:44 +0200]:
My device is Huwai- EG612 USB Modem (usable with both desktops Laptops)
with data, SMS facility.
This 3G internet modem device is working good for internet browsing but
unable to connect tryton client to the tryton server.
Connecting to
Hi,
- Can views be created without necessarily having a ModelSQL ( to show
the external data as a tree view )?
Well, I guess you can create a class that only extends ModelView and
populate the data thru a wizard.
To have it outside of a wizard I guess the way to go would be to have
On Monday, 14 May 2012 19:17:43 UTC+2, Dominique Chabord wrote:
why noy seting the party unactive, so you cannot do operations on it
anywhere and you have to ask for unactive parties to read them ?
Because even if blacklisted, action should still be performed on them and
the list (forms)
Hi,
I ran into this know bug http://bugs.tryton.org/issue1860 and wrote a patch
for it. It seems to work well from my side but I guess more people testing
would be nice :)
Emma
--
tryton@googlegroups.com mailing list
On Friday, 11 May 2012 15:40:45 UTC+2, Nicolas Évrard wrote:
You should publish a code review so that people can test it easily.
Here is the link to the code review: http://codereview.tryton.org/369001/
--
tryton@googlegroups.com mailing list
I think it will be good to have a global “rethink” of this
functionnality.
I don't like notification areas but the huge white square used as the
form title could be used to display some visual indications. Similarly
the same icons could be used in the treeviews.
But I don't know
But to be back on the topic, I think that a patch adding the image
widget to the list view would be accepted.
Ok, I'll try to work on this by the end of the week
--
tryton@googlegroups.com mailing list
On Tuesday, 8 May 2012 17:50:31 UTC+2, Cédric Krier wrote:
I don't think the huge white square is the right place to put
information about the current record in form view because it is the same
white square displayed in the list view. So it is bad to have different
meaning for the same
On Tuesday, May 8, 2012 7:43:31 PM UTC+2, Cédric Krier wrote:
So then we must define a global schema for the colors that will be
customizable on the client side with preferences.
I propose to use the color names:
https://en.wikipedia.org/wiki/ANSI_escape_code#Colors
8 colors seems to
to the
general tryton public and if I code it and provide the patch, would you be
willing to integrate it to the official tryton client?
Thanks
Emma
--
tryton@googlegroups.com mailing list
to fit the line height).
So my question is the same, if I code it and provide a patch, do you think
it could be something of interest for the tryton community and would you be
willing to integrate it to the official tryton client?
Thanks
Emma
--
tryton@googlegroups.com mailing list
).
But it's what I've been asked and I guess colors can still be good and
that's probably why is is already available in tree views
Emma
--
tryton@googlegroups.com mailing list
On Thursday, 3 May 2012 15:49:33 UTC+2, Nicolas Évrard wrote:
In fact it is already available because we use it for the icons.
in ir/ui/icon.xml:
It works for stock icons but what about content of binary fields?
--
tryton@googlegroups.com mailing list
On Thursday, 3 May 2012 17:33:19 UTC+2, grasbauer wrote:
We had a very similar request from a client:
...
In the form we putted an image width field.function(field.binary('State
Image'),'get_state_image'). In the module we are streaming the images to
the client depending of the state
Hi everyone,
I have always hated writing views by hand so I wrote a small script
that uses proteus to generate a basic view for new models. I thought
some of you might be interested so here it is:
http://new.lasolution.be/build_view.tar.gz
I place the script at the root of my trytond install
40 matches
Mail list logo
