[ovirt-devel] oVirt 3.5.0 Second Alpha postponed due to jenkins issues

2014-06-05 Thread Sandro Bonazzola
Hi,
we discovered that some projects jenkins nightly build jobs weren't providing 
nightly rpms in the last week.
In order to allow basic sanity testing before releasing second alpha, its 
release has been postponed to tomorrow.
Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


[ovirt-devel] GetCaps for jsonrpc

2014-06-05 Thread Piotr Kliczewski
Hi all,

I would like to see whether there are any suggestions how we can
provide information like:
- lastClient
- lastClientIface - network interface on which client connected

In the code prior to jsonrpc changes every time new request (new
connection) was received clientIF threadLocal was updated with client
information.

This code was implemented in xml binding and now we need to provide
similar information for jsonrpc. There is difference that we keep
connection open for jsonrpc so we can't provide behavior as described
above. We can update client information when connection is
established.

Is that OK or are there any suggestions how to update this information?

Thanks,
Piotr
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] jQuery?

2014-06-05 Thread Vojtech Szocs


- Original Message -
> From: "Greg Sheremeta" 
> To: devel@ovirt.org
> Cc: "Alexander Wels" , "Vojtech Szocs" 
> Sent: Wednesday, June 4, 2014 3:19:23 AM
> Subject: jQuery?
> 
> Does anyone see an issue with adding jQuery to GwtHostPage? Some PatternFly
> widgets require bootstrap.min.js which requires jQuery.

My understanding is that PatternFly is essentially a "skin" of Bootstrap CSS,
which doesn't imply the need for using Bootstrap _JavaScript_ library (which
needs jQuery) to deal with widgets in JavaScript runtime.

I thought that the purpose of "gwtbootstrap3" GWT module (integration with
Bootstrap CSS framework) was to provide such widgets in context of GWT app.
If not, what is then the purpose of "gwtbootstrap3" module?

In other words, doesn't "gwtbootstrap3" module provide us with all widgets
we need?

> 
> Thanks,
> Greg
> 
> Greg Sheremeta
> Red Hat, Inc.
> Sr. Software Engineer, RHEV
> Cell: 919-807-1086
> gsher...@redhat.com
> 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] jQuery?

2014-06-05 Thread Greg Sheremeta
- Original Message -
> From: "Vojtech Szocs" 
> To: "Greg Sheremeta" 
> Cc: devel@ovirt.org, "Alexander Wels" 
> Sent: Thursday, June 5, 2014 9:26:19 AM
> Subject: Re: jQuery?
> 
> 
> - Original Message -
> > From: "Greg Sheremeta" 
> > To: devel@ovirt.org
> > Cc: "Alexander Wels" , "Vojtech Szocs"
> > 
> > Sent: Wednesday, June 4, 2014 3:19:23 AM
> > Subject: jQuery?
> > 
> > Does anyone see an issue with adding jQuery to GwtHostPage? Some PatternFly
> > widgets require bootstrap.min.js which requires jQuery.
> 
> My understanding is that PatternFly is essentially a "skin" of Bootstrap CSS,
> which doesn't imply the need for using Bootstrap _JavaScript_ library (which
> needs jQuery) to deal with widgets in JavaScript runtime.
> 

Any JavaScript-enabled widgets (like tooltips) do require bootstrap.js and
jquery.js. The only reason I didn't add them in the main PatternFly patch
is that we didn't need them back then. But now we need them.

> I thought that the purpose of "gwtbootstrap3" GWT module (integration with
> Bootstrap CSS framework) was to provide such widgets in context of GWT app.
> If not, what is then the purpose of "gwtbootstrap3" module?

gwtbootstrap3 provides renderings of GWT widgets that are compatible with
bootstrap css. It does not rewrite the jQuery code into GWT-JavaScript code.

> 
> In other words, doesn't "gwtbootstrap3" module provide us with all widgets
> we need?

I wouldn't say "provide." It enables using the widgets more easily from GWT.

Take a look at 
https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
line 521 on down.

It simply wraps everything for ease-of-use from GWT / UIBinder.

Greg

> 
> > 
> > Thanks,
> > Greg
> > 
> > Greg Sheremeta
> > Red Hat, Inc.
> > Sr. Software Engineer, RHEV
> > Cell: 919-807-1086
> > gsher...@redhat.com
> > 
> > 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] GetCaps for jsonrpc

2014-06-05 Thread Dan Kenigsberg
On Thu, Jun 05, 2014 at 02:35:01PM +0200, Piotr Kliczewski wrote:
> Hi all,
> 
> I would like to see whether there are any suggestions how we can
> provide information like:
> - lastClient
> - lastClientIface - network interface on which client connected
> 
> In the code prior to jsonrpc changes every time new request (new
> connection) was received clientIF threadLocal was updated with client
> information.
> 
> This code was implemented in xml binding and now we need to provide
> similar information for jsonrpc. There is difference that we keep
> connection open for jsonrpc so we can't provide behavior as described
> above. We can update client information when connection is
> established.

That's fine by me - as long as the connection is established,
lastClientIface does not change anyway (if I understand correctly).

Bare in mind that lastClientIface is Vdsm's guess on the network
interface on top of which the client connection is comming through.

It is used when Vdsm is run on a fresh host, and Engine would like to
know on top of which interface should it configure the management
network
http://www.ovirt.org/Features/Normalized_ovirtmgmt_Initialization

> 
> Is that OK or are there any suggestions how to update this information?

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] jQuery?

2014-06-05 Thread Vojtech Szocs


- Original Message -
> From: "Greg Sheremeta" 
> To: "Vojtech Szocs" 
> Cc: devel@ovirt.org, "Alexander Wels" 
> Sent: Thursday, June 5, 2014 3:44:14 PM
> Subject: Re: jQuery?
> 
> - Original Message -
> > From: "Vojtech Szocs" 
> > To: "Greg Sheremeta" 
> > Cc: devel@ovirt.org, "Alexander Wels" 
> > Sent: Thursday, June 5, 2014 9:26:19 AM
> > Subject: Re: jQuery?
> > 
> > 
> > - Original Message -
> > > From: "Greg Sheremeta" 
> > > To: devel@ovirt.org
> > > Cc: "Alexander Wels" , "Vojtech Szocs"
> > > 
> > > Sent: Wednesday, June 4, 2014 3:19:23 AM
> > > Subject: jQuery?
> > > 
> > > Does anyone see an issue with adding jQuery to GwtHostPage? Some
> > > PatternFly
> > > widgets require bootstrap.min.js which requires jQuery.
> > 
> > My understanding is that PatternFly is essentially a "skin" of Bootstrap
> > CSS,
> > which doesn't imply the need for using Bootstrap _JavaScript_ library
> > (which
> > needs jQuery) to deal with widgets in JavaScript runtime.
> > 
> 
> Any JavaScript-enabled widgets (like tooltips) do require bootstrap.js and
> jquery.js.

I'm not sure this is the only way. gwtbootstrap3 could do the same thing,
after all its code becomes JavaScript in the end. I think there is no real
difference (conceptually) between bootstrap.js vs gwtbootstrap3, each one
can use JavaScript to implement widgets like tooltips. In the end it boils
down to styling DOM elements with CSS classes, so Bootstrap CSS framework
is the lowest common denominator.

> The only reason I didn't add them in the main PatternFly patch
> is that we didn't need them back then. But now we need them.

Hm, I assume you mean this:

  http://getbootstrap.com/javascript/#tooltips

these are jQuery plugins, apparently bootstrap.js builds on top of jQuery
to ease the work with DOM elements. For example:

  $('#example').tooltip(options)

will register mouse listeners on given element that control the tooltip.

Anyway, the tooltip behavior is just JavaScript + setting CSS classes,
not really related to jQuery.

However, I found this:

  
https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java

so it seems that gwtbootstrap3 _does_ support things like tooltips.

EDIT: see my comment below, Tooltip.java depends on jQuery, you're right.

> 
> > I thought that the purpose of "gwtbootstrap3" GWT module (integration with
> > Bootstrap CSS framework) was to provide such widgets in context of GWT app.
> > If not, what is then the purpose of "gwtbootstrap3" module?
> 
> gwtbootstrap3 provides renderings of GWT widgets that are compatible with
> bootstrap css. It does not rewrite the jQuery code into GWT-JavaScript code.
> 
> > 
> > In other words, doesn't "gwtbootstrap3" module provide us with all widgets
> > we need?
> 
> I wouldn't say "provide." It enables using the widgets more easily from GWT.
> 
> Take a look at
> https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
> line 521 on down.
> 
> It simply wraps everything for ease-of-use from GWT / UIBinder.

You are correct. So gwtbootstrap3 requires jQuery. I didn't know
this, just realized this now after looking at Tooltip.java code.

So gwtbootstrap3 is just a thin GWT wrapper to bootstrap.js which
implies the need for jQuery. (Originally I thought it's not just
a thin wrapper.)

Considering above, I'm OK with adding jQuery to GWT UI host page.

BTW, we could do this via 

Re: [ovirt-devel] jQuery?

2014-06-05 Thread Greg Sheremeta


- Original Message -
> From: "Vojtech Szocs" 
> To: "Greg Sheremeta" 
> Cc: devel@ovirt.org, "Alexander Wels" 
> Sent: Thursday, June 5, 2014 10:49:45 AM
> Subject: Re: jQuery?
> 
> 
> 
> - Original Message -
> > From: "Greg Sheremeta" 
> > To: "Vojtech Szocs" 
> > Cc: devel@ovirt.org, "Alexander Wels" 
> > Sent: Thursday, June 5, 2014 3:44:14 PM
> > Subject: Re: jQuery?
> > 
> > - Original Message -
> > > From: "Vojtech Szocs" 
> > > To: "Greg Sheremeta" 
> > > Cc: devel@ovirt.org, "Alexander Wels" 
> > > Sent: Thursday, June 5, 2014 9:26:19 AM
> > > Subject: Re: jQuery?
> > > 
> > > 
> > > - Original Message -
> > > > From: "Greg Sheremeta" 
> > > > To: devel@ovirt.org
> > > > Cc: "Alexander Wels" , "Vojtech Szocs"
> > > > 
> > > > Sent: Wednesday, June 4, 2014 3:19:23 AM
> > > > Subject: jQuery?
> > > > 
> > > > Does anyone see an issue with adding jQuery to GwtHostPage? Some
> > > > PatternFly
> > > > widgets require bootstrap.min.js which requires jQuery.
> > > 
> > > My understanding is that PatternFly is essentially a "skin" of Bootstrap
> > > CSS,
> > > which doesn't imply the need for using Bootstrap _JavaScript_ library
> > > (which
> > > needs jQuery) to deal with widgets in JavaScript runtime.
> > > 
> > 
> > Any JavaScript-enabled widgets (like tooltips) do require bootstrap.js and
> > jquery.js.
> 
> I'm not sure this is the only way. gwtbootstrap3 could do the same thing,
> after all its code becomes JavaScript in the end. I think there is no real
> difference (conceptually) between bootstrap.js vs gwtbootstrap3, each one
> can use JavaScript to implement widgets like tooltips. In the end it boils
> down to styling DOM elements with CSS classes, so Bootstrap CSS framework
> is the lowest common denominator.
> 
> > The only reason I didn't add them in the main PatternFly patch
> > is that we didn't need them back then. But now we need them.
> 
> Hm, I assume you mean this:
> 
>   http://getbootstrap.com/javascript/#tooltips
> 
> these are jQuery plugins, apparently bootstrap.js builds on top of jQuery
> to ease the work with DOM elements. For example:
> 
>   $('#example').tooltip(options)
> 
> will register mouse listeners on given element that control the tooltip.
> 
> Anyway, the tooltip behavior is just JavaScript + setting CSS classes,
> not really related to jQuery.
> 
> However, I found this:
> 
>   
> https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
> 
> so it seems that gwtbootstrap3 _does_ support things like tooltips.
> 
> EDIT: see my comment below, Tooltip.java depends on jQuery, you're right.
> 
> > 
> > > I thought that the purpose of "gwtbootstrap3" GWT module (integration
> > > with
> > > Bootstrap CSS framework) was to provide such widgets in context of GWT
> > > app.
> > > If not, what is then the purpose of "gwtbootstrap3" module?
> > 
> > gwtbootstrap3 provides renderings of GWT widgets that are compatible with
> > bootstrap css. It does not rewrite the jQuery code into GWT-JavaScript
> > code.
> > 
> > > 
> > > In other words, doesn't "gwtbootstrap3" module provide us with all
> > > widgets
> > > we need?
> > 
> > I wouldn't say "provide." It enables using the widgets more easily from
> > GWT.
> > 
> > Take a look at
> > https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
> > line 521 on down.
> > 
> > It simply wraps everything for ease-of-use from GWT / UIBinder.
> 
> You are correct. So gwtbootstrap3 requires jQuery. I didn't know
> this, just realized this now after looking at Tooltip.java code.
> 
> So gwtbootstrap3 is just a thin GWT wrapper to bootstrap.js which
> implies the need for jQuery. (Originally I thought it's not just
> a thin wrapper.)
> 
> Considering above, I'm OK with adding jQuery to GWT UI host page.
> 
> BTW, we could do this via 

Re: [ovirt-devel] jQuery?

2014-06-05 Thread Einav Cohen
> - Original Message -
> From: "Greg Sheremeta" 
> Sent: Tuesday, June 3, 2014 9:19:23 PM
> 
> Does anyone see an issue with adding jQuery to GwtHostPage? Some PatternFly
> widgets require bootstrap.min.js which requires jQuery.

apologies in advance for the complete ignorance here: 

- is there any kind of potential collision that can occur between the gwt 
javascript and the jQuery javascript? 

- is jQuery expected to substantially affect performance / loading time 
on the client side or anything like that?

> 
> Thanks,
> Greg
> 
> Greg Sheremeta
> Red Hat, Inc.
> Sr. Software Engineer, RHEV
> Cell: 919-807-1086
> gsher...@redhat.com
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] jQuery?

2014-06-05 Thread Greg Sheremeta


- Original Message -
> From: "Einav Cohen" 
> To: "Greg Sheremeta" 
> Cc: devel@ovirt.org
> Sent: Thursday, June 5, 2014 11:43:24 AM
> Subject: Re: [ovirt-devel] jQuery?
> 
> > - Original Message -
> > From: "Greg Sheremeta" 
> > Sent: Tuesday, June 3, 2014 9:19:23 PM
> > 
> > Does anyone see an issue with adding jQuery to GwtHostPage? Some PatternFly
> > widgets require bootstrap.min.js which requires jQuery.
> 
> apologies in advance for the complete ignorance here:
> 
> - is there any kind of potential collision that can occur between the gwt
> javascript and the jQuery javascript?

Namespace collision -- no. jQuery registers itself globally as '$' and 'jQuery',
and neither GWT itself nor our GWT code use those names anywhere.

However, there can be behavior conflicts. I'm currently debugging a problem
where tooltips aren't destroyed when grid refreshes happen. The jQuery widget
doesn't 'know' that the GWT widget it's attached to was destroyed :(

> 
> - is jQuery expected to substantially affect performance / loading time
> on the client side or anything like that?

First-load time will be negligible and cached.

Mass-use of bad selectors could decrease browser performance. I think we should
very rarely use jQuery in oVirt. Usages of it should be very justifiable.

Greg

> 
> > 
> > Thanks,
> > Greg
> > 
> > Greg Sheremeta
> > Red Hat, Inc.
> > Sr. Software Engineer, RHEV
> > Cell: 919-807-1086
> > gsher...@redhat.com
> > 
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> > 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] jQuery?

2014-06-05 Thread Vojtech Szocs


- Original Message -
> From: "Greg Sheremeta" 
> To: "Vojtech Szocs" 
> Cc: devel@ovirt.org, "Alexander Wels" 
> Sent: Thursday, June 5, 2014 4:58:51 PM
> Subject: Re: jQuery?
> 
> 
> 
> - Original Message -
> > From: "Vojtech Szocs" 
> > To: "Greg Sheremeta" 
> > Cc: devel@ovirt.org, "Alexander Wels" 
> > Sent: Thursday, June 5, 2014 10:49:45 AM
> > Subject: Re: jQuery?
> > 
> > 
> > 
> > - Original Message -
> > > From: "Greg Sheremeta" 
> > > To: "Vojtech Szocs" 
> > > Cc: devel@ovirt.org, "Alexander Wels" 
> > > Sent: Thursday, June 5, 2014 3:44:14 PM
> > > Subject: Re: jQuery?
> > > 
> > > - Original Message -
> > > > From: "Vojtech Szocs" 
> > > > To: "Greg Sheremeta" 
> > > > Cc: devel@ovirt.org, "Alexander Wels" 
> > > > Sent: Thursday, June 5, 2014 9:26:19 AM
> > > > Subject: Re: jQuery?
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: "Greg Sheremeta" 
> > > > > To: devel@ovirt.org
> > > > > Cc: "Alexander Wels" , "Vojtech Szocs"
> > > > > 
> > > > > Sent: Wednesday, June 4, 2014 3:19:23 AM
> > > > > Subject: jQuery?
> > > > > 
> > > > > Does anyone see an issue with adding jQuery to GwtHostPage? Some
> > > > > PatternFly
> > > > > widgets require bootstrap.min.js which requires jQuery.
> > > > 
> > > > My understanding is that PatternFly is essentially a "skin" of
> > > > Bootstrap
> > > > CSS,
> > > > which doesn't imply the need for using Bootstrap _JavaScript_ library
> > > > (which
> > > > needs jQuery) to deal with widgets in JavaScript runtime.
> > > > 
> > > 
> > > Any JavaScript-enabled widgets (like tooltips) do require bootstrap.js
> > > and
> > > jquery.js.
> > 
> > I'm not sure this is the only way. gwtbootstrap3 could do the same thing,
> > after all its code becomes JavaScript in the end. I think there is no real
> > difference (conceptually) between bootstrap.js vs gwtbootstrap3, each one
> > can use JavaScript to implement widgets like tooltips. In the end it boils
> > down to styling DOM elements with CSS classes, so Bootstrap CSS framework
> > is the lowest common denominator.
> > 
> > > The only reason I didn't add them in the main PatternFly patch
> > > is that we didn't need them back then. But now we need them.
> > 
> > Hm, I assume you mean this:
> > 
> >   http://getbootstrap.com/javascript/#tooltips
> > 
> > these are jQuery plugins, apparently bootstrap.js builds on top of jQuery
> > to ease the work with DOM elements. For example:
> > 
> >   $('#example').tooltip(options)
> > 
> > will register mouse listeners on given element that control the tooltip.
> > 
> > Anyway, the tooltip behavior is just JavaScript + setting CSS classes,
> > not really related to jQuery.
> > 
> > However, I found this:
> > 
> >   
> > https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
> > 
> > so it seems that gwtbootstrap3 _does_ support things like tooltips.
> > 
> > EDIT: see my comment below, Tooltip.java depends on jQuery, you're right.
> > 
> > > 
> > > > I thought that the purpose of "gwtbootstrap3" GWT module (integration
> > > > with
> > > > Bootstrap CSS framework) was to provide such widgets in context of GWT
> > > > app.
> > > > If not, what is then the purpose of "gwtbootstrap3" module?
> > > 
> > > gwtbootstrap3 provides renderings of GWT widgets that are compatible with
> > > bootstrap css. It does not rewrite the jQuery code into GWT-JavaScript
> > > code.
> > > 
> > > > 
> > > > In other words, doesn't "gwtbootstrap3" module provide us with all
> > > > widgets
> > > > we need?
> > > 
> > > I wouldn't say "provide." It enables using the widgets more easily from
> > > GWT.
> > > 
> > > Take a look at
> > > https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
> > > line 521 on down.
> > > 
> > > It simply wraps everything for ease-of-use from GWT / UIBinder.
> > 
> > You are correct. So gwtbootstrap3 requires jQuery. I didn't know
> > this, just realized this now after looking at Tooltip.java code.
> > 
> > So gwtbootstrap3 is just a thin GWT wrapper to bootstrap.js which
> > implies the need for jQuery. (Originally I thought it's not just
> > a thin wrapper.)
> > 
> > Considering above, I'm OK with adding jQuery to GWT UI host page.
> > 
> > BTW, we could do this via 

Re: [ovirt-devel] jQuery?

2014-06-05 Thread Vojtech Szocs


- Original Message -
> From: "Greg Sheremeta" 
> To: "Einav Cohen" 
> Cc: devel@ovirt.org
> Sent: Thursday, June 5, 2014 5:51:08 PM
> Subject: Re: [ovirt-devel] jQuery?
> 
> 
> 
> - Original Message -
> > From: "Einav Cohen" 
> > To: "Greg Sheremeta" 
> > Cc: devel@ovirt.org
> > Sent: Thursday, June 5, 2014 11:43:24 AM
> > Subject: Re: [ovirt-devel] jQuery?
> > 
> > > - Original Message -
> > > From: "Greg Sheremeta" 
> > > Sent: Tuesday, June 3, 2014 9:19:23 PM
> > > 
> > > Does anyone see an issue with adding jQuery to GwtHostPage? Some
> > > PatternFly
> > > widgets require bootstrap.min.js which requires jQuery.
> > 
> > apologies in advance for the complete ignorance here:
> > 
> > - is there any kind of potential collision that can occur between the gwt
> > javascript and the jQuery javascript?
> 
> Namespace collision -- no. jQuery registers itself globally as '$' and
> 'jQuery',
> and neither GWT itself nor our GWT code use those names anywhere.

+1 this is my understanding as well.

> 
> However, there can be behavior conflicts. I'm currently debugging a problem
> where tooltips aren't destroyed when grid refreshes happen. The jQuery widget
> doesn't 'know' that the GWT widget it's attached to was destroyed :(

In cases like this one, could we close/destroy the tooltip via GWT JSNI code?

> 
> > 
> > - is jQuery expected to substantially affect performance / loading time
> > on the client side or anything like that?
> 
> First-load time will be negligible and cached.
> 
> Mass-use of bad selectors could decrease browser performance. I think we
> should
> very rarely use jQuery in oVirt. Usages of it should be very justifiable.

Exactly, any direct use of jQuery should be justified by a solid reason.

> 
> Greg
> 
> > 
> > > 
> > > Thanks,
> > > Greg
> > > 
> > > Greg Sheremeta
> > > Red Hat, Inc.
> > > Sr. Software Engineer, RHEV
> > > Cell: 919-807-1086
> > > gsher...@redhat.com
> > > 
> > > ___
> > > Devel mailing list
> > > Devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > > 
> > 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] conflicts in constants file

2014-06-05 Thread Vojtech Szocs
Hi Gilad, sorry for my late reply :(

Just like Alex suggested, you can simply put your changes near
existing constants which are related to what you're working on.

(Or maybe try to reuse existing constants, if possible.)

I agree that currently we have huge (Common)ApplicationConstants
files, however for future we were considering using alternative
i18n implementation which could retrieve constants at runtime,
essentially eliminating "locale" permutation vector during GWT
compilation, speeding up GWT compile times. (With this approach,
constant values wouldn't be "baked into" JavaScript application,
but rather exposed for use at runtime.)

Vojtech


- Original Message -
> From: "Alexander Wels" 
> To: devel@ovirt.org
> Cc: "Gilad Chaplik" , "Vojtech Szocs" 
> Sent: Tuesday, June 3, 2014 2:16:22 PM
> Subject: Re: [ovirt-devel] conflicts in constants file
> 
> Gilad,
> 
> I found the easiest way to avoid the conflicts in the location files is to
> not
> add your new messages at the bottom of the file like everyone else. I try to
> find messages that are related to what I am working on and put my new
> messages
> there. Since everyone puts their new messages at the bottom, and mine aren't
> at the bottom there are no conflicts for me. Or at least they are much rarer.
> 
> Alexander
> 
> On Tuesday, June 03, 2014 03:06:49 AM Gilad Chaplik wrote:
> > Hi Vojtech,
> > 
> > it seems that foreach rebase I do I get git conflicts for constants files
> > (java iface localization files).
> > 
> > do you have a way to solve that?
> > 
> > Thanks,
> > Gilad.
> > 
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] Python-GTK User Portal

2014-06-05 Thread Itamar Heim

On 05/27/2014 02:25 PM, Vojtech Szocs wrote:



- Original Message -

From: "Antoni Segura Puimedon" 
To: "Michal Skrivanek" 
Cc: "Vojtech Szocs" , "Amador Pahim" , 
devel@ovirt.org
Sent: Tuesday, May 27, 2014 1:16:17 PM
Subject: Re: [ovirt-devel] Python-GTK User Portal



- Original Message -

From: "Michal Skrivanek" 
To: "Vojtech Szocs" , "Amador Pahim" 
Cc: devel@ovirt.org
Sent: Tuesday, May 27, 2014 12:54:16 PM
Subject: Re: [ovirt-devel] Python-GTK User Portal


On May 27, 2014, at 12:48 , Vojtech Szocs  wrote:


Hi, this project looks nice!

Indeed, UserPortal can be sluggish on devices with limited performance.
Going for custom, light-weight UserPortal sounds like a natural choice,
"samples-portals" repo sounds like a natural place :)

Note that (very) soon I'm going to present a prototype of oVirt.js,
SDK for working with oVirt within JavaScript environment. In future,
we could implement light-weight UserPortal as web application, or we
could use Node.js to host the client application code.



It's awesomely simple. Even as a non-web application I think it's worth
it:)
It can be a great way how to find out what are we missing in SDK, what is
not
effective enough for big scale usage, debugging, etc..

I wouldn't hesitate much to throw the current user portal away and replace
it
with this. One small bug in current portal takes longer to fix than this
whole thing…


I admit that current development workflow is quite complex for a rather simple
application that UserPortal should be. Also consider that UserPortal contains
two things, "Basic" + "Extended" section, so it's more complex by design :)

Anyway, JavaScript SDK should bring more possibilities.



I would not necessarily throw it away, but I'm completely for moving such a
project to the oVirt umbrella. We could even have an image for thin clients
that boots into this sort of application.


Yes, thin clients for specific devices (like ones with limited performance)
are clients too, so I agree with above.


we could do a 'lighter' version of it (well, we could do a 'basic html' 
version if we really want it light...)








Thanks,
michal



Regards,
Vojtech


- Original Message -

From: "Amador Pahim" 
To: devel@ovirt.org
Sent: Tuesday, May 27, 2014 4:53:35 AM
Subject: [ovirt-devel] Python-GTK User Portal

Olá,

I'm running some tests with Raspberry Pi, trying to use it as a thin
client to oVirt.

My initial test was just open web User Portal using a browser. But
RasPi limited performance is leading browser to repeatedly show the
warning for "unresponsive script" before load the portal.

Trying to have a lighter way to access oVirt with the same functions
as in "Basic" User Portal, I wrote this Python-GTK client. Its
performance in RasPi is quite acceptable currently.




I'm wondering if you guys have any interest in putting the bits
somewhere along with the project repositories. Maybe in
"samples-portals"?

Source code:
https://github.com/apahim/ovirt-userportal-gtk

Here a screenshot with it in action:
http://pbrd.co/1onSA7O

Best Regards,
--
Pahim
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel




___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Python-GTK User Portal

2014-06-05 Thread Antoni Segura Puimedon


- Original Message -
> From: "Itamar Heim" 
> To: "Vojtech Szocs" , "Antoni Segura Puimedon" 
> 
> Cc: devel@ovirt.org
> Sent: Thursday, June 5, 2014 9:36:01 PM
> Subject: Re: [ovirt-devel] Python-GTK User Portal
> 
> On 05/27/2014 02:25 PM, Vojtech Szocs wrote:
> >
> >
> > - Original Message -
> >> From: "Antoni Segura Puimedon" 
> >> To: "Michal Skrivanek" 
> >> Cc: "Vojtech Szocs" , "Amador Pahim"
> >> , devel@ovirt.org
> >> Sent: Tuesday, May 27, 2014 1:16:17 PM
> >> Subject: Re: [ovirt-devel] Python-GTK User Portal
> >>
> >>
> >>
> >> - Original Message -
> >>> From: "Michal Skrivanek" 
> >>> To: "Vojtech Szocs" , "Amador Pahim"
> >>> 
> >>> Cc: devel@ovirt.org
> >>> Sent: Tuesday, May 27, 2014 12:54:16 PM
> >>> Subject: Re: [ovirt-devel] Python-GTK User Portal
> >>>
> >>>
> >>> On May 27, 2014, at 12:48 , Vojtech Szocs  wrote:
> >>>
>  Hi, this project looks nice!
> 
>  Indeed, UserPortal can be sluggish on devices with limited performance.
>  Going for custom, light-weight UserPortal sounds like a natural choice,
>  "samples-portals" repo sounds like a natural place :)
> 
>  Note that (very) soon I'm going to present a prototype of oVirt.js,
>  SDK for working with oVirt within JavaScript environment. In future,
>  we could implement light-weight UserPortal as web application, or we
>  could use Node.js to host the client application code.
> >>>
> >>>
> >>> It's awesomely simple. Even as a non-web application I think it's worth
> >>> it:)
> >>> It can be a great way how to find out what are we missing in SDK, what is
> >>> not
> >>> effective enough for big scale usage, debugging, etc..
> >>>
> >>> I wouldn't hesitate much to throw the current user portal away and
> >>> replace
> >>> it
> >>> with this. One small bug in current portal takes longer to fix than this
> >>> whole thing…
> >
> > I admit that current development workflow is quite complex for a rather
> > simple
> > application that UserPortal should be. Also consider that UserPortal
> > contains
> > two things, "Basic" + "Extended" section, so it's more complex by design :)
> >
> > Anyway, JavaScript SDK should bring more possibilities.
> >
> >>
> >> I would not necessarily throw it away, but I'm completely for moving such
> >> a
> >> project to the oVirt umbrella. We could even have an image for thin
> >> clients
> >> that boots into this sort of application.
> >
> > Yes, thin clients for specific devices (like ones with limited performance)
> > are clients too, so I agree with above.
> 
> we could do a 'lighter' version of it (well, we could do a 'basic html'
> version if we really want it light...)

The problem for ultra-thin clients, like the raspberry pi is, is that the 
browser
itself is a taking a lot of resources.  But in any case, making a lighter user
portal, once wayland is stable and using midori, it could be performant enough
for ultra-thin clients.

> 
> >
> >>
> >>>
> >>> Thanks,
> >>> michal
> >>>
> 
>  Regards,
>  Vojtech
> 
> 
>  - Original Message -
> > From: "Amador Pahim" 
> > To: devel@ovirt.org
> > Sent: Tuesday, May 27, 2014 4:53:35 AM
> > Subject: [ovirt-devel] Python-GTK User Portal
> >
> > Olá,
> >
> > I'm running some tests with Raspberry Pi, trying to use it as a thin
> > client to oVirt.
> >
> > My initial test was just open web User Portal using a browser. But
> > RasPi limited performance is leading browser to repeatedly show the
> > warning for "unresponsive script" before load the portal.
> >
> > Trying to have a lighter way to access oVirt with the same functions
> > as in "Basic" User Portal, I wrote this Python-GTK client. Its
> > performance in RasPi is quite acceptable currently.
> >>>
> >
> > I'm wondering if you guys have any interest in putting the bits
> > somewhere along with the project repositories. Maybe in
> > "samples-portals"?
> >
> > Source code:
> > https://github.com/apahim/ovirt-userportal-gtk
> >
> > Here a screenshot with it in action:
> > http://pbrd.co/1onSA7O
> >
> > Best Regards,
> > --
> > Pahim
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>  ___
>  Devel mailing list
>  Devel@ovirt.org
>  http://lists.ovirt.org/mailman/listinfo/devel
> >>>
> >>> ___
> >>> Devel mailing list
> >>> Devel@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >>>
> >>
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] jQuery?

2014-06-05 Thread Greg Sheremeta


- Original Message -
> From: "Vojtech Szocs" 
> To: "Greg Sheremeta" 
> Cc: "Einav Cohen" , devel@ovirt.org
> Sent: Thursday, June 5, 2014 12:29:41 PM
> Subject: Re: [ovirt-devel] jQuery?
> 
> 
> 
> - Original Message -
> > From: "Greg Sheremeta" 
> > To: "Einav Cohen" 
> > Cc: devel@ovirt.org
> > Sent: Thursday, June 5, 2014 5:51:08 PM
> > Subject: Re: [ovirt-devel] jQuery?
> > 
> > 
> > 
> > - Original Message -
> > > From: "Einav Cohen" 
> > > To: "Greg Sheremeta" 
> > > Cc: devel@ovirt.org
> > > Sent: Thursday, June 5, 2014 11:43:24 AM
> > > Subject: Re: [ovirt-devel] jQuery?
> > > 
> > > > - Original Message -
> > > > From: "Greg Sheremeta" 
> > > > Sent: Tuesday, June 3, 2014 9:19:23 PM
> > > > 
> > > > Does anyone see an issue with adding jQuery to GwtHostPage? Some
> > > > PatternFly
> > > > widgets require bootstrap.min.js which requires jQuery.
> > > 
> > > apologies in advance for the complete ignorance here:
> > > 
> > > - is there any kind of potential collision that can occur between the gwt
> > > javascript and the jQuery javascript?
> > 
> > Namespace collision -- no. jQuery registers itself globally as '$' and
> > 'jQuery',
> > and neither GWT itself nor our GWT code use those names anywhere.
> 
> +1 this is my understanding as well.
> 
> > 
> > However, there can be behavior conflicts. I'm currently debugging a problem
> > where tooltips aren't destroyed when grid refreshes happen. The jQuery
> > widget
> > doesn't 'know' that the GWT widget it's attached to was destroyed :(
> 
> In cases like this one, could we close/destroy the tooltip via GWT JSNI code?

Yep, that is what I'm trying to do.

> 
> > 
> > > 
> > > - is jQuery expected to substantially affect performance / loading time
> > > on the client side or anything like that?
> > 
> > First-load time will be negligible and cached.
> > 
> > Mass-use of bad selectors could decrease browser performance. I think we
> > should
> > very rarely use jQuery in oVirt. Usages of it should be very justifiable.
> 
> Exactly, any direct use of jQuery should be justified by a solid reason.
> 
> > 
> > Greg
> > 
> > > 
> > > > 
> > > > Thanks,
> > > > Greg
> > > > 
> > > > Greg Sheremeta
> > > > Red Hat, Inc.
> > > > Sr. Software Engineer, RHEV
> > > > Cell: 919-807-1086
> > > > gsher...@redhat.com
> > > > 
> > > > ___
> > > > Devel mailing list
> > > > Devel@ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > > 
> > > 
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> > 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


Re: [ovirt-devel] jQuery?

2014-06-05 Thread Greg Sheremeta


- Original Message -
> From: "Vojtech Szocs" 
> To: "Greg Sheremeta" 
> Cc: devel@ovirt.org, "Alexander Wels" 
> Sent: Thursday, June 5, 2014 12:19:34 PM
> Subject: Re: jQuery?
> 
> 
> 
> - Original Message -
> > From: "Greg Sheremeta" 
> > To: "Vojtech Szocs" 
> > Cc: devel@ovirt.org, "Alexander Wels" 
> > Sent: Thursday, June 5, 2014 4:58:51 PM
> > Subject: Re: jQuery?
> > 
> > 
> > 
> > - Original Message -
> > > From: "Vojtech Szocs" 
> > > To: "Greg Sheremeta" 
> > > Cc: devel@ovirt.org, "Alexander Wels" 
> > > Sent: Thursday, June 5, 2014 10:49:45 AM
> > > Subject: Re: jQuery?
> > > 
> > > 
> > > 
> > > - Original Message -
> > > > From: "Greg Sheremeta" 
> > > > To: "Vojtech Szocs" 
> > > > Cc: devel@ovirt.org, "Alexander Wels" 
> > > > Sent: Thursday, June 5, 2014 3:44:14 PM
> > > > Subject: Re: jQuery?
> > > > 
> > > > - Original Message -
> > > > > From: "Vojtech Szocs" 
> > > > > To: "Greg Sheremeta" 
> > > > > Cc: devel@ovirt.org, "Alexander Wels" 
> > > > > Sent: Thursday, June 5, 2014 9:26:19 AM
> > > > > Subject: Re: jQuery?
> > > > > 
> > > > > 
> > > > > - Original Message -
> > > > > > From: "Greg Sheremeta" 
> > > > > > To: devel@ovirt.org
> > > > > > Cc: "Alexander Wels" , "Vojtech Szocs"
> > > > > > 
> > > > > > Sent: Wednesday, June 4, 2014 3:19:23 AM
> > > > > > Subject: jQuery?
> > > > > > 
> > > > > > Does anyone see an issue with adding jQuery to GwtHostPage? Some
> > > > > > PatternFly
> > > > > > widgets require bootstrap.min.js which requires jQuery.
> > > > > 
> > > > > My understanding is that PatternFly is essentially a "skin" of
> > > > > Bootstrap
> > > > > CSS,
> > > > > which doesn't imply the need for using Bootstrap _JavaScript_ library
> > > > > (which
> > > > > needs jQuery) to deal with widgets in JavaScript runtime.
> > > > > 
> > > > 
> > > > Any JavaScript-enabled widgets (like tooltips) do require bootstrap.js
> > > > and
> > > > jquery.js.
> > > 
> > > I'm not sure this is the only way. gwtbootstrap3 could do the same thing,
> > > after all its code becomes JavaScript in the end. I think there is no
> > > real
> > > difference (conceptually) between bootstrap.js vs gwtbootstrap3, each one
> > > can use JavaScript to implement widgets like tooltips. In the end it
> > > boils
> > > down to styling DOM elements with CSS classes, so Bootstrap CSS framework
> > > is the lowest common denominator.
> > > 
> > > > The only reason I didn't add them in the main PatternFly patch
> > > > is that we didn't need them back then. But now we need them.
> > > 
> > > Hm, I assume you mean this:
> > > 
> > >   http://getbootstrap.com/javascript/#tooltips
> > > 
> > > these are jQuery plugins, apparently bootstrap.js builds on top of jQuery
> > > to ease the work with DOM elements. For example:
> > > 
> > >   $('#example').tooltip(options)
> > > 
> > > will register mouse listeners on given element that control the tooltip.
> > > 
> > > Anyway, the tooltip behavior is just JavaScript + setting CSS classes,
> > > not really related to jQuery.
> > > 
> > > However, I found this:
> > > 
> > >   
> > > https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
> > > 
> > > so it seems that gwtbootstrap3 _does_ support things like tooltips.
> > > 
> > > EDIT: see my comment below, Tooltip.java depends on jQuery, you're right.
> > > 
> > > > 
> > > > > I thought that the purpose of "gwtbootstrap3" GWT module (integration
> > > > > with
> > > > > Bootstrap CSS framework) was to provide such widgets in context of
> > > > > GWT
> > > > > app.
> > > > > If not, what is then the purpose of "gwtbootstrap3" module?
> > > > 
> > > > gwtbootstrap3 provides renderings of GWT widgets that are compatible
> > > > with
> > > > bootstrap css. It does not rewrite the jQuery code into GWT-JavaScript
> > > > code.
> > > > 
> > > > > 
> > > > > In other words, doesn't "gwtbootstrap3" module provide us with all
> > > > > widgets
> > > > > we need?
> > > > 
> > > > I wouldn't say "provide." It enables using the widgets more easily from
> > > > GWT.
> > > > 
> > > > Take a look at
> > > > https://github.com/gwtbootstrap3/gwtbootstrap3/blob/master/gwtbootstrap3/src/main/java/org/gwtbootstrap3/client/ui/Tooltip.java
> > > > line 521 on down.
> > > > 
> > > > It simply wraps everything for ease-of-use from GWT / UIBinder.
> > > 
> > > You are correct. So gwtbootstrap3 requires jQuery. I didn't know
> > > this, just realized this now after looking at Tooltip.java code.
> > > 
> > > So gwtbootstrap3 is just a thin GWT wrapper to bootstrap.js which
> > > implies the need for jQuery. (Originally I thought it's not just
> > > a thin wrapper.)
> > > 
> > > Considering above, I'm OK with adding jQuery to GWT UI host page.
> > > 
> > > BTW, we could do this via