public inbox for [email protected]
help / color / mirror / Atom feedShowstopper desktop runtime issue
16+ messages / 7 participants
[nested] [flat]
* Showstopper desktop runtime issue
@ 2018-03-22 09:49 Dave Page <[email protected]>
2018-03-22 10:05 ` Re: Showstopper desktop runtime issue Akshay Joshi <[email protected]>
2018-03-22 10:19 ` Re: Showstopper desktop runtime issue Neel Patel <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
0 siblings, 3 replies; 16+ messages in thread
From: Dave Page @ 2018-03-22 09:49 UTC (permalink / raw)
To: pgadmin-hackers; +Cc: Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Joao Pedro De Almeida Pereira <[email protected]>; Robert Eckhardt <[email protected]>
All,
As you know, the 3.0 release is currently on hold as we discovered late
yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
later. This is because the GTK project, and later Gnome, have removed
support for the System Tray on which the new runtime relies.
They have replaced it with a notification mechanism, however this doesn't
really meet our needs as what we want is a place (the tray icon) to attach
a menu to control the pgAdmin server; we don't really use notifications as
such.
I see a number of possible ways around this:
1) Return to the previous runtime. I think this is at best a short-term
solution, as the re-visited Annulen version of the QtWebKit seems to be
getting little attention at the moment, and this would re-introduce many
known bugs caused by WebKit.
2) Re-work the current runtime code to remove the tray icon, and utilise
desktop/start menu items to signal the running instance to show the logs,
configure the server, exit etc. This should work, but will be kinda klunky.
3) Put effort into polishing Joao's Electron based runtime. This might be a
good long term solution as it would remove the need to have any C++ code of
our own, and might allow us to use Electron's update mechanism to do
software updates. The downsides are that we would lose support for dockable
tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
currently support.
Thoughts and comments please folks? How do we want to proceed? I'm
currently leaning towards 2 for v3, and possibly moving to 3 in the long
term.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-22 10:05 ` Akshay Joshi <[email protected]>
2 siblings, 0 replies; 16+ messages in thread
From: Akshay Joshi @ 2018-03-22 10:05 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Joao Pedro De Almeida Pereira <[email protected]>; Robert Eckhardt <[email protected]>
On Thu, Mar 22, 2018 at 3:19 PM, Dave Page <[email protected]> wrote:
> All,
>
> As you know, the 3.0 release is currently on hold as we discovered late
> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
> later. This is because the GTK project, and later Gnome, have removed
> support for the System Tray on which the new runtime relies.
>
> They have replaced it with a notification mechanism, however this doesn't
> really meet our needs as what we want is a place (the tray icon) to attach
> a menu to control the pgAdmin server; we don't really use notifications as
> such.
>
> I see a number of possible ways around this:
>
> 1) Return to the previous runtime. I think this is at best a short-term
> solution, as the re-visited Annulen version of the QtWebKit seems to be
> getting little attention at the moment, and this would re-introduce many
> known bugs caused by WebKit.
>
> 2) Re-work the current runtime code to remove the tray icon, and utilise
> desktop/start menu items to signal the running instance to show the logs,
> configure the server, exit etc. This should work, but will be kinda klunky.
>
> 3) Put effort into polishing Joao's Electron based runtime. This might be
> a good long term solution as it would remove the need to have any C++ code
> of our own, and might allow us to use Electron's update mechanism to do
> software updates. The downsides are that we would lose support for dockable
> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
> currently support.
>
> Thoughts and comments please folks? How do we want to proceed? I'm
> currently leaning towards 2 for v3, and possibly moving to 3 in the long
> term.
>
Option 2 seems good to me.
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
*Akshay Joshi*
*Sr. Software Architect *
*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-22 10:19 ` Neel Patel <[email protected]>
2018-03-22 10:22 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2 siblings, 1 reply; 16+ messages in thread
From: Neel Patel @ 2018-03-22 10:19 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers; Akshay Joshi <[email protected]>; Ashesh Vashi <[email protected]>; Joao Pedro De Almeida Pereira <[email protected]>; Robert Eckhardt <[email protected]>
Hi,
On Thu, Mar 22, 2018 at 3:19 PM, Dave Page <[email protected]> wrote:
> All,
>
> As you know, the 3.0 release is currently on hold as we discovered late
> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
> later. This is because the GTK project, and later Gnome, have removed
> support for the System Tray on which the new runtime relies.
>
> They have replaced it with a notification mechanism, however this doesn't
> really meet our needs as what we want is a place (the tray icon) to attach
> a menu to control the pgAdmin server; we don't really use notifications as
> such.
>
> I see a number of possible ways around this:
>
> 1) Return to the previous runtime. I think this is at best a short-term
> solution, as the re-visited Annulen version of the QtWebKit seems to be
> getting little attention at the moment, and this would re-introduce many
> known bugs caused by WebKit.
>
> 2) Re-work the current runtime code to remove the tray icon, and utilise
> desktop/start menu items to signal the running instance to show the logs,
> configure the server, exit etc. This should work, but will be kinda klunky.
>
> 3) Put effort into polishing Joao's Electron based runtime. This might be
> a good long term solution as it would remove the need to have any C++ code
> of our own, and might allow us to use Electron's update mechanism to do
> software updates. The downsides are that we would lose support for dockable
> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
> currently support.
>
> Thoughts and comments please folks? How do we want to proceed? I'm
> currently leaning towards 2 for v3, and possibly moving to 3 in the long
> term.
>
As per our previous efforts on Qt's web rendering framework, I am not in
favor of adding it again as it add lots of dependency and complexity.
I would suggest to go for option 2 - To re-work the current runtime code
and find out how to get already running instance of pgadmin4.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:19 ` Re: Showstopper desktop runtime issue Neel Patel <[email protected]>
@ 2018-03-22 10:22 ` Dave Page <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Dave Page @ 2018-03-22 10:22 UTC (permalink / raw)
To: Neel Patel <[email protected]>; +Cc: pgadmin-hackers; Akshay Joshi <[email protected]>; Ashesh Vashi <[email protected]>; Joao Pedro De Almeida Pereira <[email protected]>; Robert Eckhardt <[email protected]>
On Thu, Mar 22, 2018 at 10:19 AM, Neel Patel <[email protected]>
wrote:
> Hi,
>
> On Thu, Mar 22, 2018 at 3:19 PM, Dave Page <[email protected]> wrote:
>
>> All,
>>
>> As you know, the 3.0 release is currently on hold as we discovered late
>> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
>> later. This is because the GTK project, and later Gnome, have removed
>> support for the System Tray on which the new runtime relies.
>>
>> They have replaced it with a notification mechanism, however this doesn't
>> really meet our needs as what we want is a place (the tray icon) to attach
>> a menu to control the pgAdmin server; we don't really use notifications as
>> such.
>>
>> I see a number of possible ways around this:
>>
>> 1) Return to the previous runtime. I think this is at best a short-term
>> solution, as the re-visited Annulen version of the QtWebKit seems to be
>> getting little attention at the moment, and this would re-introduce many
>> known bugs caused by WebKit.
>>
>> 2) Re-work the current runtime code to remove the tray icon, and utilise
>> desktop/start menu items to signal the running instance to show the logs,
>> configure the server, exit etc. This should work, but will be kinda klunky.
>>
>> 3) Put effort into polishing Joao's Electron based runtime. This might be
>> a good long term solution as it would remove the need to have any C++ code
>> of our own, and might allow us to use Electron's update mechanism to do
>> software updates. The downsides are that we would lose support for dockable
>> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
>> currently support.
>>
>> Thoughts and comments please folks? How do we want to proceed? I'm
>> currently leaning towards 2 for v3, and possibly moving to 3 in the long
>> term.
>>
>
> As per our previous efforts on Qt's web rendering framework, I am not in
> favor of adding it again as it add lots of dependency and complexity.
> I would suggest to go for option 2 - To re-work the current runtime code
> and find out how to get already running instance of pgadmin4.
>
We have a shared memory interlock as well as temp/lock files that encode
the executable path into their name that handles that already, though it
doesn't seem to be working quite as expected when you run from a Mac
Appbundle (which Akshay is working on). The issue would be how we signal
the running instance and tell it to do something, e.g. exit.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-22 10:48 ` Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2 siblings, 1 reply; 16+ messages in thread
From: Murtuza Zabuawala @ 2018-03-22 10:48 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Joao Pedro De Almeida Pereira <[email protected]>; Robert Eckhardt <[email protected]>
On Thu, Mar 22, 2018 at 3:19 PM, Dave Page <[email protected]> wrote:
> All,
>
> As you know, the 3.0 release is currently on hold as we discovered late
> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
> later. This is because the GTK project, and later Gnome, have removed
> support for the System Tray on which the new runtime relies.
>
> They have replaced it with a notification mechanism, however this doesn't
> really meet our needs as what we want is a place (the tray icon) to attach
> a menu to control the pgAdmin server; we don't really use notifications as
> such.
>
> I see a number of possible ways around this:
>
> 1) Return to the previous runtime. I think this is at best a short-term
> solution, as the re-visited Annulen version of the QtWebKit seems to be
> getting little attention at the moment, and this would re-introduce many
> known bugs caused by WebKit.
>
I would not prefer going back after seeing QtWebkit & QtWebEngine issues
in the past.
>
> 2) Re-work the current runtime code to remove the tray icon, and utilise
> desktop/start menu items to signal the running instance to show the logs,
> configure the server, exit etc. This should work, but will be kinda klunky.
>
+1
>
> 3) Put effort into polishing Joao's Electron based runtime. This might be
> a good long term solution as it would remove the need to have any C++ code
> of our own, and might allow us to use Electron's update mechanism to do
> software updates. The downsides are that we would lose support for dockable
> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
> currently support.
>
This is a good alternative but there are some downside of Electron,
- It takes longer to start application
- High cpu & ram usage (I have used Slack, Atom & VSCode all of them used
Electron)
> Thoughts and comments please folks? How do we want to proceed? I'm
> currently leaning towards 2 for v3, and possibly moving to 3 in the long
> term.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
@ 2018-03-22 14:57 ` Joao De Almeida Pereira <[email protected]>
2018-03-22 16:14 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
0 siblings, 2 replies; 16+ messages in thread
From: Joao De Almeida Pereira @ 2018-03-22 14:57 UTC (permalink / raw)
To: Murtuza Zabuawala <[email protected]>; +Cc: Dave Page <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
Hello Hackers,
Here is our take on the 3 options present:
1) QtWebkit and QtWebEngine
Pros:
- Webkit is a mature technology that as been around for some time
- Apparently the Fork of Webkit we were using as been catching up
Cons:
- We are using a Fork
- It is to far behind of the today browsers and the competition keep
evolving making it even harder for them to catch up
- Problems with the environment from the past, lagginess, lack of support
2) Rework runtime to find a running PGAdmin and attach to it
Pros:
- We already made the big move from Webkit to this version
- Add smarts to the application to do not run itself if it is already
running, or kill the currently running application
Cons:
- More C++ code thrown around
- Add more dependency on our QT application
- Have specific code for Gnome, not even a OS version but a window manager
3) Electron
Pros:
- Full Javascript runtime, no more C++ code to handle
- Self packaging for all the environments
Cons:
- No fully supported on Linux based OS with old libstdc++, (This might
solve the problem: https://github.com/mattermost/desktop/issues/312)
- CPU/RAM high utilization (Found a issues around and the majority of them
have solutions like CSS animations running or settings on the created
windows)
- Electron does not support tabs by default, only HTML tabs
After combing through these options with some pros and cons here are my
thoughts:
1) This options was always cluncky from the beginning, the fact that we are
working with a browser that is currently 26k commits behind Webkit:master
is concerning. So I do not believe this is a viable option. As a personal
opinion is we need to release fast, then we should go with what we have now
and not go back to this option.
2) This option is not very appealing to me, because we would be pilling
code into the QT portion of the application, that I hope we remove in the
future, that currently is untested to solve a problem caused by a Window
Manager......
I would be more in favor of creating a Application Indicator that would
support 2 actions, Kill running pgAdmins and launch the browser to access
them. There is a lot of interesting websites that talk about this, and how
to develop. I had to download one to have a docker indicator..... But as I
said in a previous thread, I believe that this should be a 3rd party
application and not a first class citizen on pgAdmin, as the majority of
the ones that I found are.
3) Electron can to play, first when we though about removing QTWebkit,
because it always packs a browser with it and also and there is a very big
Open Source Community being it. It came back again when when we saw that we
were ready to ditch the browser. (As a personal note I dislike applications
that I install in my machine and pop browser open to do anything, this is a
personal issue that I would like to see if it was shared by others that was
why we decided to park Electron for a second time. Because if our users are
ok with it there is no need to add extra complexity to the product)
The most interesting thing about the cons that I found in Electron there is
an issue open for them and a bunch of different solutions to try to handle
it, or even advises on how to handle it. This option also allow us to focus
less on browser compatibility as the main target of our development will
become Chromium which is the base of browsers like UC Browser, Vivaldi,
Opera, Google Chrome.
As you could see from my long long email, I am biased towards options 3,
not because I started the push for it, but because I believe it is the
right step for this product. This being said, I think that releasing now
with this current issue is Ok as a first step to somewhere.
Thanks
Joao
On Thu, Mar 22, 2018 at 6:48 AM Murtuza Zabuawala <
[email protected]> wrote:
> On Thu, Mar 22, 2018 at 3:19 PM, Dave Page <[email protected]> wrote:
>
>> All,
>>
>> As you know, the 3.0 release is currently on hold as we discovered late
>> yesterday that the re-vamped desktop runtime will not run on Gnome 3.26 and
>> later. This is because the GTK project, and later Gnome, have removed
>> support for the System Tray on which the new runtime relies.
>>
>> They have replaced it with a notification mechanism, however this doesn't
>> really meet our needs as what we want is a place (the tray icon) to attach
>> a menu to control the pgAdmin server; we don't really use notifications as
>> such.
>>
>> I see a number of possible ways around this:
>>
>> 1) Return to the previous runtime. I think this is at best a short-term
>> solution, as the re-visited Annulen version of the QtWebKit seems to be
>> getting little attention at the moment, and this would re-introduce many
>> known bugs caused by WebKit.
>>
> I would not prefer going back after seeing QtWebkit & QtWebEngine issues
> in the past.
>
>
>>
>> 2) Re-work the current runtime code to remove the tray icon, and utilise
>> desktop/start menu items to signal the running instance to show the logs,
>> configure the server, exit etc. This should work, but will be kinda klunky.
>>
> +1
>
>
>>
>> 3) Put effort into polishing Joao's Electron based runtime. This might be
>> a good long term solution as it would remove the need to have any C++ code
>> of our own, and might allow us to use Electron's update mechanism to do
>> software updates. The downsides are that we would lose support for dockable
>> tabs (new windows only), and it wouldn't work on CentOS/RHEL 6 which we
>> currently support.
>>
> This is a good alternative but there are some downside of Electron,
> - It takes longer to start application
> - High cpu & ram usage (I have used Slack, Atom & VSCode all of them used
> Electron)
>
>
>> Thoughts and comments please folks? How do we want to proceed? I'm
>> currently leaning towards 2 for v3, and possibly moving to 3 in the long
>> term.
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
@ 2018-03-22 16:14 ` Dave Page <[email protected]>
1 sibling, 0 replies; 16+ messages in thread
From: Dave Page @ 2018-03-22 16:14 UTC (permalink / raw)
To: Joao De Almeida Pereira <[email protected]>; +Cc: Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
Hi
On Thu, Mar 22, 2018 at 2:57 PM, Joao De Almeida Pereira <
[email protected]> wrote:
> Hello Hackers,
> Here is our take on the 3 options present:
> 1) QtWebkit and QtWebEngine
>
> Pros:
> - Webkit is a mature technology that as been around for some time
> - Apparently the Fork of Webkit we were using as been catching up
> Cons:
> - We are using a Fork
> - It is to far behind of the today browsers and the competition keep
> evolving making it even harder for them to catch up
> - Problems with the environment from the past, lagginess, lack of support
>
> 2) Rework runtime to find a running PGAdmin and attach to it
>
> Pros:
> - We already made the big move from Webkit to this version
> - Add smarts to the application to do not run itself if it is already
> running, or kill the currently running application
>
> Cons:
> - More C++ code thrown around
> - Add more dependency on our QT application
> - Have specific code for Gnome, not even a OS version but a window manager
>
> 3) Electron
>
> Pros:
> - Full Javascript runtime, no more C++ code to handle
> - Self packaging for all the environments
> Cons:
> - No fully supported on Linux based OS with old libstdc++, (This might
> solve the problem: https://github.com/mattermost/desktop/issues/312)
> - CPU/RAM high utilization (Found a issues around and the majority of them
> have solutions like CSS animations running or settings on the created
> windows)
> - Electron does not support tabs by default, only HTML tabs
>
> After combing through these options with some pros and cons here are my
> thoughts:
> 1) This options was always cluncky from the beginning, the fact that we
> are working with a browser that is currently 26k commits behind
> Webkit:master is concerning. So I do not believe this is a viable option.
> As a personal opinion is we need to release fast, then we should go with
> what we have now and not go back to this option.
> 2) This option is not very appealing to me, because we would be pilling
> code into the QT portion of the application, that I hope we remove in the
> future, that currently is untested to solve a problem caused by a Window
> Manager......
> I would be more in favor of creating a Application Indicator that would
> support 2 actions, Kill running pgAdmins and launch the browser to access
> them. There is a lot of interesting websites that talk about this, and how
> to develop. I had to download one to have a docker indicator..... But as I
> said in a previous thread, I believe that this should be a 3rd party
> application and not a first class citizen on pgAdmin, as the majority of
> the ones that I found are.
> 3) Electron can to play, first when we though about removing QTWebkit,
> because it always packs a browser with it and also and there is a very big
> Open Source Community being it. It came back again when when we saw that we
> were ready to ditch the browser. (As a personal note I dislike applications
> that I install in my machine and pop browser open to do anything, this is a
> personal issue that I would like to see if it was shared by others that was
> why we decided to park Electron for a second time. Because if our users are
> ok with it there is no need to add extra complexity to the product)
> The most interesting thing about the cons that I found in Electron there
> is an issue open for them and a bunch of different solutions to try to
> handle it, or even advises on how to handle it. This option also allow us
> to focus less on browser compatibility as the main target of our
> development will become Chromium which is the base of browsers like UC
> Browser, Vivaldi, Opera, Google Chrome.
>
> As you could see from my long long email, I am biased towards options 3,
> not because I started the push for it, but because I believe it is the
> right step for this product. This being said, I think that releasing now
> with this current issue is Ok as a first step to somewhere.
>
I think in the longer term, 3 is probably the best option. Whilst the
current architecture (where it works) is a good improvement and gets rid of
the QtWebKit/QtWebEngine problems, I'm not a huge fan of having a server
and browser; I much prefer the idea of having a single app.
How much effort do you think it would be to get the Electron based browser
to a usable state, in which everything is nicely packaged and buildable,
but without the tab support?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
@ 2018-03-22 16:17 ` Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
1 sibling, 1 reply; 16+ messages in thread
From: Magnus Hagander @ 2018-03-22 16:17 UTC (permalink / raw)
To: Joao De Almeida Pereira <[email protected]>; +Cc: Murtuza Zabuawala <[email protected]>; Dave Page <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira <
[email protected]> wrote:
> Hello Hackers,
> Here is our take on the 3 options present:
>
This looks like a good summary, so I'm going to pick this one to comment on
:)
> 1) QtWebkit and QtWebEngine
>
> Pros:
> - Webkit is a mature technology that as been around for some time
> - Apparently the Fork of Webkit we were using as been catching up
> Cons:
> - We are using a Fork
> - It is to far behind of the today browsers and the competition keep
> evolving making it even harder for them to catch up
> - Problems with the environment from the past, lagginess, lack of support
>
>
Yeah, this one hasn't exactly caused a "little" set of complaints so far.
It might be workable for absolute stop-gap, but not beyond that.
> 2) Rework runtime to find a running PGAdmin and attach to it
>
> Pros:
> - We already made the big move from Webkit to this version
> - Add smarts to the application to do not run itself if it is already
> running, or kill the currently running application
>
> Cons:
> - More C++ code thrown around
> - Add more dependency on our QT application
> - Have specific code for Gnome, not even a OS version but a window manager
>
Annoying as it is, I think this is the least bad option at this point.
3) Electron
>
> Pros:
> - Full Javascript runtime, no more C++ code to handle
> - Self packaging for all the environments
> Cons:
> - No fully supported on Linux based OS with old libstdc++, (This might
> solve the problem: https://github.com/mattermost/desktop/issues/312)
>
Losing support for things like RHEL6 would make it completely unworkable
for several of my largest customers. Particularly in large enterprise
organisations, this would be a very substantial issue.
> - CPU/RAM high utilization (Found a issues around and the majority of them
> have solutions like CSS animations running or settings on the created
> windows)
>
This does sound bad. But do we actually know if this is worse in Electron
than it is in the option #2? I mean sure, we point to things like Slack,
but that may not be because of electron, it may be because the app running
inside it?
> - Electron does not support tabs by default, only HTML tabs
>
I think that also makes it a showstopper. This was another one of the main
complaints I have personally heard from people going from pgadmin3 ->
pgadmin4, and enough to make people not want to use it at all. It would be
really bad to go back to that.
After combing through these options with some pros and cons here are my
> thoughts:
> 1) This options was always cluncky from the beginning, the fact that we
> are working with a browser that is currently 26k commits behind
> Webkit:master is concerning. So I do not believe this is a viable option.
> As a personal opinion is we need to release fast, then we should go with
> what we have now and not go back to this option.
>
Yeah, that option definitely has no future long-term.
> 2) This option is not very appealing to me, because we would be pilling
> code into the QT portion of the application, that I hope we remove in the
> future, that currently is untested to solve a problem caused by a Window
> Manager......
> I would be more in favor of creating a Application Indicator that would
> support 2 actions, Kill running pgAdmins and launch the browser to access
> them. There is a lot of interesting websites that talk about this, and how
> to develop. I had to download one to have a docker indicator..... But as I
> said in a previous thread, I believe that this should be a 3rd party
> application and not a first class citizen on pgAdmin, as the majority of
> the ones that I found are.
>
I can't comment on the specific ways to sort it out, but I think *basing*
things in option 2 is by far the best option. If it's just an additional
add-on that can be made a dependency of the packages it's not a huge
problem (provided this add-on is available on the major platforms like
rhel, ubuntu, debian of course)
> 3) Electron can to play, first when we though about removing QTWebkit,
> because it always packs a browser with it and also and there is a very big
> Open Source Community being it. It came back again when when we saw that we
> were ready to ditch the browser. (As a personal note I dislike applications
> that I install in my machine and pop browser open to do anything, this is a
> personal issue that I would like to see if it was shared by others that was
> why we decided to park Electron for a second time. Because if our users are
> ok with it there is no need to add extra complexity to the product)
> The most interesting thing about the cons that I found in Electron there
> is an issue open for them and a bunch of different solutions to try to
> handle it, or even advises on how to handle it. This option also allow us
> to focus less on browser compatibility as the main target of our
> development will become Chromium which is the base of browsers like UC
> Browser, Vivaldi, Opera, Google Chrome.
>
Please don't ever give up browser independence for the *web* version of
pgadmin. Don't be That Project (TM).
(And don't give up on proper tabs either, but I'm sure Electron might catch
up in that eventually -- and the issue around RHEL6 will also go away
eventually)
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
@ 2018-03-22 16:28 ` Dave Page <[email protected]>
2018-03-22 16:38 ` Re: Showstopper desktop runtime issue Robert Eckhardt <[email protected]>
2018-03-22 16:58 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-23 10:08 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
0 siblings, 3 replies; 16+ messages in thread
From: Dave Page @ 2018-03-22 16:28 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Joao De Almeida Pereira <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
Hi
On Thu, Mar 22, 2018 at 4:17 PM, Magnus Hagander <[email protected]>
wrote:
>
>
> On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira <
> [email protected]> wrote:
>
>> Hello Hackers,
>> Here is our take on the 3 options present:
>>
>
> This looks like a good summary, so I'm going to pick this one to comment
> on :)
>
:-)
>
>
>
>
>> 1) QtWebkit and QtWebEngine
>>
>
>> Pros:
>> - Webkit is a mature technology that as been around for some time
>> - Apparently the Fork of Webkit we were using as been catching up
>> Cons:
>> - We are using a Fork
>> - It is to far behind of the today browsers and the competition keep
>> evolving making it even harder for them to catch up
>> - Problems with the environment from the past, lagginess, lack of support
>>
>>
> Yeah, this one hasn't exactly caused a "little" set of complaints so far.
> It might be workable for absolute stop-gap, but not beyond that.
>
Right.
>
>
>
>> 2) Rework runtime to find a running PGAdmin and attach to it
>>
>> Pros:
>> - We already made the big move from Webkit to this version
>> - Add smarts to the application to do not run itself if it is already
>> running, or kill the currently running application
>>
>> Cons:
>> - More C++ code thrown around
>> - Add more dependency on our QT application
>> - Have specific code for Gnome, not even a OS version but a window manager
>>
>
>
> Annoying as it is, I think this is the least bad option at this point.
>
>
> 3) Electron
>>
>> Pros:
>> - Full Javascript runtime, no more C++ code to handle
>> - Self packaging for all the environments
>> Cons:
>> - No fully supported on Linux based OS with old libstdc++, (This might
>> solve the problem: https://github.com/mattermost/desktop/issues/312)
>>
>
>
> Losing support for things like RHEL6 would make it completely unworkable
> for several of my largest customers. Particularly in large enterprise
> organisations, this would be a very substantial issue.
>
That's good to know. There are clunky workarounds (shipping different libcs
for example, but that potentially adds licensing issues).
Sidenote: It would only be an issue for desktop mode. Web mode should not
be affected.
>
>
>
>> - CPU/RAM high utilization (Found a issues around and the majority of
>> them have solutions like CSS animations running or settings on the created
>> windows)
>>
>
> This does sound bad. But do we actually know if this is worse in Electron
> than it is in the option #2? I mean sure, we point to things like Slack,
> but that may not be because of electron, it may be because the app running
> inside it?
>
We don't know for sure, but we do know that Chrome in general is a bit of a
hog. It's certainly not a stretch to think a combination of those things
are why people (correctly) see browser based apps as being more resource
hungry.
>
>
>
>> - Electron does not support tabs by default, only HTML tabs
>>
>
> I think that also makes it a showstopper. This was another one of the main
> complaints I have personally heard from people going from pgadmin3 ->
> pgadmin4, and enough to make people not want to use it at all. It would be
> really bad to go back to that.
>
To clarify; it would mean no tabs, but not single window. That was already
working in the PoC. In other words, helpfiles, the debugger and query tools
could all be opened in new windows, just not tabs on the same window that
could be docked and un-docked.
I suspect for most people that would be enough.
>
>
>
> After combing through these options with some pros and cons here are my
>> thoughts:
>> 1) This options was always cluncky from the beginning, the fact that we
>> are working with a browser that is currently 26k commits behind
>> Webkit:master is concerning. So I do not believe this is a viable option.
>> As a personal opinion is we need to release fast, then we should go with
>> what we have now and not go back to this option.
>>
>
> Yeah, that option definitely has no future long-term.
>
>
>
>> 2) This option is not very appealing to me, because we would be pilling
>> code into the QT portion of the application, that I hope we remove in the
>> future, that currently is untested to solve a problem caused by a Window
>> Manager......
>> I would be more in favor of creating a Application Indicator that would
>> support 2 actions, Kill running pgAdmins and launch the browser to access
>> them. There is a lot of interesting websites that talk about this, and how
>> to develop. I had to download one to have a docker indicator..... But as I
>> said in a previous thread, I believe that this should be a 3rd party
>> application and not a first class citizen on pgAdmin, as the majority of
>> the ones that I found are.
>>
>
> I can't comment on the specific ways to sort it out, but I think *basing*
> things in option 2 is by far the best option. If it's just an additional
> add-on that can be made a dependency of the packages it's not a huge
> problem (provided this add-on is available on the major platforms like
> rhel, ubuntu, debian of course)
>
It would just be a modified version of what we have. Instead of having an
icon in the system tray, we'd probably have multiple Start Menu icons to
replace the tray icon menu. They would have to signal a running instance to
do something, or become a new instance and then do the something if nothing
is running already.
>
>
>
>
>> 3) Electron can to play, first when we though about removing QTWebkit,
>> because it always packs a browser with it and also and there is a very big
>> Open Source Community being it. It came back again when when we saw that we
>> were ready to ditch the browser. (As a personal note I dislike applications
>> that I install in my machine and pop browser open to do anything, this is a
>> personal issue that I would like to see if it was shared by others that was
>> why we decided to park Electron for a second time. Because if our users are
>> ok with it there is no need to add extra complexity to the product)
>> The most interesting thing about the cons that I found in Electron there
>> is an issue open for them and a bunch of different solutions to try to
>> handle it, or even advises on how to handle it. This option also allow us
>> to focus less on browser compatibility as the main target of our
>> development will become Chromium which is the base of browsers like UC
>> Browser, Vivaldi, Opera, Google Chrome.
>>
>
> Please don't ever give up browser independence for the *web* version of
> pgadmin. Don't be That Project (TM).
>
Not on my watch!
>
> (And don't give up on proper tabs either, but I'm sure Electron might
> catch up in that eventually -- and the issue around RHEL6 will also go away
> eventually)
>
RHEL 6 is in support until 2024, though it's already halfway through the
maintenance 2 phase. It's definitely going, but we really don't know how
many folks might still be using it in production on systems they're
updating and using pgAdmin on. That last bit is important; many folks will
continue to run production servers on RHEL/CentOS 6 for years, but how many
are using them for client-side stuff or actively updating things like
pgAdmin on them?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-22 16:38 ` Robert Eckhardt <[email protected]>
2018-03-23 10:10 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2 siblings, 1 reply; 16+ messages in thread
From: Robert Eckhardt @ 2018-03-22 16:38 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Joao De Almeida Pereira <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>
On Thu, Mar 22, 2018 at 12:28 PM, Dave Page <[email protected]> wrote:
> Hi
>
> On Thu, Mar 22, 2018 at 4:17 PM, Magnus Hagander <[email protected]>
> wrote:
>
>>
>>
>> On Thu, Mar 22, 2018 at 3:57 PM, Joao De Almeida Pereira <
>> [email protected]> wrote:
>>
>>> Hello Hackers,
>>> Here is our take on the 3 options present:
>>>
>>
>> This looks like a good summary, so I'm going to pick this one to comment
>> on :)
>>
>
> :-)
>
>
>>
>>
>>
>>
>>> 1) QtWebkit and QtWebEngine
>>>
>>
>>> Pros:
>>> - Webkit is a mature technology that as been around for some time
>>> - Apparently the Fork of Webkit we were using as been catching up
>>> Cons:
>>> - We are using a Fork
>>> - It is to far behind of the today browsers and the competition keep
>>> evolving making it even harder for them to catch up
>>> - Problems with the environment from the past, lagginess, lack of support
>>>
>>>
>> Yeah, this one hasn't exactly caused a "little" set of complaints so far.
>> It might be workable for absolute stop-gap, but not beyond that.
>>
>
> Right.
>
>
>>
>>
>>
>>> 2) Rework runtime to find a running PGAdmin and attach to it
>>>
>>> Pros:
>>> - We already made the big move from Webkit to this version
>>> - Add smarts to the application to do not run itself if it is already
>>> running, or kill the currently running application
>>>
>>> Cons:
>>> - More C++ code thrown around
>>> - Add more dependency on our QT application
>>> - Have specific code for Gnome, not even a OS version but a window
>>> manager
>>>
>>
>>
>> Annoying as it is, I think this is the least bad option at this point.
>>
>>
>> 3) Electron
>>>
>>> Pros:
>>> - Full Javascript runtime, no more C++ code to handle
>>> - Self packaging for all the environments
>>> Cons:
>>> - No fully supported on Linux based OS with old libstdc++, (This might
>>> solve the problem: https://github.com/mattermost/desktop/issues/312)
>>>
>>
>>
>> Losing support for things like RHEL6 would make it completely unworkable
>> for several of my largest customers. Particularly in large enterprise
>> organisations, this would be a very substantial issue.
>>
>
> That's good to know. There are clunky workarounds (shipping different
> libcs for example, but that potentially adds licensing issues).
>
> Sidenote: It would only be an issue for desktop mode. Web mode should not
> be affected.
>
>
>>
>>
>>
>>> - CPU/RAM high utilization (Found a issues around and the majority of
>>> them have solutions like CSS animations running or settings on the created
>>> windows)
>>>
>>
>> This does sound bad. But do we actually know if this is worse in Electron
>> than it is in the option #2? I mean sure, we point to things like Slack,
>> but that may not be because of electron, it may be because the app running
>> inside it?
>>
>
> We don't know for sure, but we do know that Chrome in general is a bit of
> a hog. It's certainly not a stretch to think a combination of those things
> are why people (correctly) see browser based apps as being more resource
> hungry.
>
I honestly think this is a fair criticism. I like electron and wish it
weren't.
>
>
>>
>>
>>
>>> - Electron does not support tabs by default, only HTML tabs
>>>
>>
>> I think that also makes it a showstopper. This was another one of the
>> main complaints I have personally heard from people going from pgadmin3 ->
>> pgadmin4, and enough to make people not want to use it at all. It would be
>> really bad to go back to that.
>>
>
> To clarify; it would mean no tabs, but not single window. That was already
> working in the PoC. In other words, helpfiles, the debugger and query tools
> could all be opened in new windows, just not tabs on the same window that
> could be docked and un-docked.
>
> I suspect for most people that would be enough.
>
Agreed, I also think that adding tabs is a doable feature it just isn't an
'out of the box' thing.
>
>
>>
>>
>>
>> After combing through these options with some pros and cons here are my
>>> thoughts:
>>> 1) This options was always cluncky from the beginning, the fact that we
>>> are working with a browser that is currently 26k commits behind
>>> Webkit:master is concerning. So I do not believe this is a viable option.
>>> As a personal opinion is we need to release fast, then we should go with
>>> what we have now and not go back to this option.
>>>
>>
>> Yeah, that option definitely has no future long-term.
>>
>>
>>
>>> 2) This option is not very appealing to me, because we would be pilling
>>> code into the QT portion of the application, that I hope we remove in the
>>> future, that currently is untested to solve a problem caused by a Window
>>> Manager......
>>> I would be more in favor of creating a Application Indicator that would
>>> support 2 actions, Kill running pgAdmins and launch the browser to access
>>> them. There is a lot of interesting websites that talk about this, and how
>>> to develop. I had to download one to have a docker indicator..... But as I
>>> said in a previous thread, I believe that this should be a 3rd party
>>> application and not a first class citizen on pgAdmin, as the majority of
>>> the ones that I found are.
>>>
>>
>> I can't comment on the specific ways to sort it out, but I think *basing*
>> things in option 2 is by far the best option. If it's just an additional
>> add-on that can be made a dependency of the packages it's not a huge
>> problem (provided this add-on is available on the major platforms like
>> rhel, ubuntu, debian of course)
>>
>
> It would just be a modified version of what we have. Instead of having an
> icon in the system tray, we'd probably have multiple Start Menu icons to
> replace the tray icon menu. They would have to signal a running instance to
> do something, or become a new instance and then do the something if nothing
> is running already.
>
>
>>
>>
>>
>>
>>> 3) Electron can to play, first when we though about removing QTWebkit,
>>> because it always packs a browser with it and also and there is a very big
>>> Open Source Community being it. It came back again when when we saw that we
>>> were ready to ditch the browser. (As a personal note I dislike applications
>>> that I install in my machine and pop browser open to do anything, this is a
>>> personal issue that I would like to see if it was shared by others that was
>>> why we decided to park Electron for a second time. Because if our users are
>>> ok with it there is no need to add extra complexity to the product)
>>> The most interesting thing about the cons that I found in Electron there
>>> is an issue open for them and a bunch of different solutions to try to
>>> handle it, or even advises on how to handle it. This option also allow us
>>> to focus less on browser compatibility as the main target of our
>>> development will become Chromium which is the base of browsers like UC
>>> Browser, Vivaldi, Opera, Google Chrome.
>>>
>>
>> Please don't ever give up browser independence for the *web* version of
>> pgadmin. Don't be That Project (TM).
>>
>
> Not on my watch!
>
>
>>
>> (And don't give up on proper tabs either, but I'm sure Electron might
>> catch up in that eventually -- and the issue around RHEL6 will also go away
>> eventually)
>>
>
> RHEL 6 is in support until 2024, though it's already halfway through the
> maintenance 2 phase. It's definitely going, but we really don't know how
> many folks might still be using it in production on systems they're
> updating and using pgAdmin on. That last bit is important; many folks will
> continue to run production servers on RHEL/CentOS 6 for years, but how many
> are using them for client-side stuff or actively updating things like
> pgAdmin on them?
>
RHEL 6 is the #1 OS for GPDB so if we have customers installing server side
or wanting to we'd be on this pretty quickly.
As an aside, I'm interested in who and how people are using the Linux
version. How many are using Linux on the desktop and how many are
installing the server. My assumption is that people using the linux distro
are installing the server but I have no actual information to base that on.
-- Rob
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 16:38 ` Re: Showstopper desktop runtime issue Robert Eckhardt <[email protected]>
@ 2018-03-23 10:10 ` Magnus Hagander <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Magnus Hagander @ 2018-03-23 10:10 UTC (permalink / raw)
To: Robert Eckhardt <[email protected]>; +Cc: Dave Page <[email protected]>; Joao De Almeida Pereira <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>
On Thu, Mar 22, 2018 at 5:38 PM, Robert Eckhardt <[email protected]>
wrote:
>
>
> On Thu, Mar 22, 2018 at 12:28 PM, Dave Page <[email protected]> wrote:
>
>>
>>> (And don't give up on proper tabs either, but I'm sure Electron might
>>> catch up in that eventually -- and the issue around RHEL6 will also go away
>>> eventually)
>>>
>>
>> RHEL 6 is in support until 2024, though it's already halfway through the
>> maintenance 2 phase. It's definitely going, but we really don't know how
>> many folks might still be using it in production on systems they're
>> updating and using pgAdmin on. That last bit is important; many folks will
>> continue to run production servers on RHEL/CentOS 6 for years, but how many
>> are using them for client-side stuff or actively updating things like
>> pgAdmin on them?
>>
>
> RHEL 6 is the #1 OS for GPDB so if we have customers installing server
> side or wanting to we'd be on this pretty quickly.
>
> As an aside, I'm interested in who and how people are using the Linux
> version. How many are using Linux on the desktop and how many are
> installing the server. My assumption is that people using the linux distro
> are installing the server but I have no actual information to base that on.
>
My experience is actually the opposite in a lot of cases. The server
pgadmin is used primarily by those of my customers who are using Windows --
mainly as a workaround for the fact that the performance experience of the
desktop app on Windows was horrible.
On Mac I don't think I've seen anybody choose the server version if it's a
primary tool for them (some still have a shared pgadmin for people who only
touch it at very infrequent cases, but it's not common). On Linux, I see a
mix.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-22 16:58 ` Dave Page <[email protected]>
2018-03-22 18:27 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-23 12:00 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2 siblings, 2 replies; 16+ messages in thread
From: Dave Page @ 2018-03-22 16:58 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Joao De Almeida Pereira <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
On Thu, Mar 22, 2018 at 4:28 PM, Dave Page <[email protected]> wrote:
>
> 2) This option is not very appealing to me, because we would be pilling
>>> code into the QT portion of the application, that I hope we remove in the
>>> future, that currently is untested to solve a problem caused by a Window
>>> Manager......
>>> I would be more in favor of creating a Application Indicator that would
>>> support 2 actions, Kill running pgAdmins and launch the browser to access
>>> them. There is a lot of interesting websites that talk about this, and how
>>> to develop. I had to download one to have a docker indicator..... But as I
>>> said in a previous thread, I believe that this should be a 3rd party
>>> application and not a first class citizen on pgAdmin, as the majority of
>>> the ones that I found are.
>>>
>>
>> I can't comment on the specific ways to sort it out, but I think *basing*
>> things in option 2 is by far the best option. If it's just an additional
>> add-on that can be made a dependency of the packages it's not a huge
>> problem (provided this add-on is available on the major platforms like
>> rhel, ubuntu, debian of course)
>>
>
> It would just be a modified version of what we have. Instead of having an
> icon in the system tray, we'd probably have multiple Start Menu icons to
> replace the tray icon menu. They would have to signal a running instance to
> do something, or become a new instance and then do the something if nothing
> is running already.
>
Of course, another option here might be to figure out that we're running
under Gnome/GTK at runtime, and if so, create an indicator icon and menu
instead of the tray icon. That is, apparently, what Skype and other similar
apps do now. The indicator icons go on the right of the top menu bar (kinda
like where tray icons go on macOS).
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 16:58 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-22 18:27 ` Joao De Almeida Pereira <[email protected]>
2018-03-23 11:27 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
1 sibling, 1 reply; 16+ messages in thread
From: Joao De Almeida Pereira @ 2018-03-22 18:27 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
Hello Hackers
In the PoC we did with Electron last month this was the point where we
stopped
What did we accomplish:
- Use Electron as a runtime and packaging solution for the application
- Support opening new windows when the preferences ask for them
- Make the application generally work
- Use Chrome as a default browser for the application
- Building scripts for all platforms using `yarn`, please review Readme
- The packaged Python version is 3.6 to Mac and Linux, and 3.4 to Windows
- In our point of view it is a simpler way to generate the installers
Work in progress:
- No random port for the server, so you can only start 1 instance per
machine
- Tab support, there is no native support for tabs in Electron. It is
possible to do that, and eventually you will see a option in the menu to
create a new tab, but for this PoC we decided to disable the creation of
tabs. Tabs need to be implemented using HTML and cannot be ripped of from
the current window, like in Chrome
- Did not test in CentOS, but tested in Ubuntu and it is working (We tried
but the electron required GLIBC 2.25 that was not on the version of CentOS
that we had)
- In Linux despite the fact that we close the window, the application is
still running and need to be killed by hand
- We didn't test Debugger opening in new window
- Loading screen has no reference to pgAdmin
- No logging file for the runtime
- Windows we are using python 3.4 and using prior version of psycopg2
2.5.6 and pycrypto 2.6.1 (The version of psycopg2 is not the correct one,
this is because we couldn't find a precompile version of psycopg2)
- This is just a spike and the code looks pretty messy. This need to be
changed in order to make it more readable and have some tests around it
- Murtuza and Fahar were not able to run the application in Windows
- Khushboo was not able to run Ubuntu version
Given this was the status at the time, we need to pick and choose what we
really want to implement right out of the box and what could be postponed.
In order to generate Windows build and ensure that the Linux build is
working we need so help. If we could have access to the machines that you
use to build pgAdmin or access to the venv folder that is generated in
these machines we could try to create a build from that.
The changes we produced still applies cleanly on master and can be found
in: https://github.com/greenplum-db/pgadmin4/tree/electron-over-master
Thanks
Victoria & Joao
On Thu, Mar 22, 2018 at 12:58 PM Dave Page <[email protected]> wrote:
> On Thu, Mar 22, 2018 at 4:28 PM, Dave Page <[email protected]> wrote:
>
>>
>> 2) This option is not very appealing to me, because we would be pilling
>>>> code into the QT portion of the application, that I hope we remove in the
>>>> future, that currently is untested to solve a problem caused by a Window
>>>> Manager......
>>>> I would be more in favor of creating a Application Indicator that would
>>>> support 2 actions, Kill running pgAdmins and launch the browser to access
>>>> them. There is a lot of interesting websites that talk about this, and how
>>>> to develop. I had to download one to have a docker indicator..... But as I
>>>> said in a previous thread, I believe that this should be a 3rd party
>>>> application and not a first class citizen on pgAdmin, as the majority of
>>>> the ones that I found are.
>>>>
>>>
>>> I can't comment on the specific ways to sort it out, but I think
>>> *basing* things in option 2 is by far the best option. If it's just an
>>> additional add-on that can be made a dependency of the packages it's not a
>>> huge problem (provided this add-on is available on the major platforms like
>>> rhel, ubuntu, debian of course)
>>>
>>
>> It would just be a modified version of what we have. Instead of having an
>> icon in the system tray, we'd probably have multiple Start Menu icons to
>> replace the tray icon menu. They would have to signal a running instance to
>> do something, or become a new instance and then do the something if nothing
>> is running already.
>>
>
> Of course, another option here might be to figure out that we're running
> under Gnome/GTK at runtime, and if so, create an indicator icon and menu
> instead of the tray icon. That is, apparently, what Skype and other similar
> apps do now. The indicator icons go on the right of the top menu bar (kinda
> like where tray icons go on macOS).
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 16:58 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 18:27 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
@ 2018-03-23 11:27 ` Dave Page <[email protected]>
0 siblings, 0 replies; 16+ messages in thread
From: Dave Page @ 2018-03-23 11:27 UTC (permalink / raw)
To: Joao De Almeida Pereira <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
--001a114110122ea58e056812b57f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi
On Thu, Mar 22, 2018 at 6:27 PM, Joao De Almeida Pereira <
[email protected]> wrote:
> Hello Hackers
>
> In the PoC we did with Electron last month this was the point where we
> stopped
>
> What did we accomplish:
> - Use Electron as a runtime and packaging solution for the application
> - Support opening new windows when the preferences ask for them
> - Make the application generally work
> - Use Chrome as a default browser for the application
> - Building scripts for all platforms using `yarn`, please review Readme
> - The packaged Python version is 3.6 to Mac and Linux, and 3.4 to Window=
s
> - In our point of view it is a simpler way to generate the installers
>
> Work in progress:
> - No random port for the server, so you can only start 1 instance per
> machine
> - Tab support, there is no native support for tabs in Electron. It is
> possible to do that, and eventually you will see a option in the menu to
> create a new tab, but for this PoC we decided to disable the creation of
> tabs. Tabs need to be implemented using HTML and cannot be ripped of from
> the current window, like in Chrome
> - Did not test in CentOS, but tested in Ubuntu and it is working (We
> tried but the electron required GLIBC 2.25 that was not on the version of
> CentOS that we had)
> - In Linux despite the fact that we close the window, the application is
> still running and need to be killed by hand
> - We didn't test Debugger opening in new window
> - Loading screen has no reference to pgAdmin
> - No logging file for the runtime
> - Windows we are using python 3.4 and using prior version of psycopg2
> 2.5.6 and pycrypto 2.6.1 (The version of psycopg2 is not the correct one,
> this is because we couldn't find a precompile version of psycopg2)
> - This is just a spike and the code looks pretty messy. This need to be
> changed in order to make it more readable and have some tests around it
> - Murtuza and Fahar were not able to run the application in Windows
> - Khushboo was not able to run Ubuntu version
>
> Given this was the status at the time, we need to pick and choose what we
> really want to implement right out of the box and what could be postponed=
.
> In order to generate Windows build and ensure that the Linux build is
> working we need so help. If we could have access to the machines that you
> use to build pgAdmin or access to the venv folder that is generated in
> these machines we could try to create a build from that.
>
> The changes we produced still applies cleanly on master and can be found
> in: https://github.com/greenplum-db/pgadmin4/tree/electron-over-master
>
>
I just tried building the PoC again, and got much further than before - in
fact I did get a working app bundle out at the end, however the dist build
did spew out the errors below:
piranha:electron dpage$ yarn dist
yarn run v1.3.2
$ ./node_modules/.bin/electron-builder
=E2=80=A2 electron-builder version=3D20.0.7
=E2=80=A2 loaded configuration file=3Dpackage.json ("build" field)
=E2=80=A2 writing effective config file=3Ddist/electron-builder.yaml
=E2=80=A2 no native production dependencies
=E2=80=A2 asar using is disabled =E2=80=94 it is strongly not recommended=
solution=3Denable
asar and use asarUnpack to unpack files that must be externally available
=E2=80=A2 packaging platform=3Ddarwin arch=3Dx64 electron=3D1.8.2
appOutDir=3Ddist/mac
=E2=80=A2 signing file=3Ddist/mac/pgAdmin 4.app identityName=3DDe=
veloper ID
Application: <redacted> identityHash=3D<redacted>
Error: Command failed: codesign --verify --deep --strict --verbose=3D2
/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin 4.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper NP.app
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper NP.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper EH.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper.app
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper.app
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper EH.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/Current/.
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/Current/.
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/.
/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin 4.app: No such
file or directory
at ChildProcess.exithandler (child_process.js:275:12)
at emitTwo (events.js:126:13)
at ChildProcess.emit (events.js:214:7)
at maybeClose (internal/child_process.js:925:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5=
)
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 16:58 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-23 12:00 ` Dave Page <[email protected]>
1 sibling, 0 replies; 16+ messages in thread
From: Dave Page @ 2018-03-23 12:00 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Joao De Almeida Pereira <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
On Thu, Mar 22, 2018 at 4:58 PM, Dave Page <[email protected]> wrote:
>
>
> On Thu, Mar 22, 2018 at 4:28 PM, Dave Page <[email protected]> wrote:
>
>>
>> 2) This option is not very appealing to me, because we would be pilling
>>>> code into the QT portion of the application, that I hope we remove in the
>>>> future, that currently is untested to solve a problem caused by a Window
>>>> Manager......
>>>> I would be more in favor of creating a Application Indicator that would
>>>> support 2 actions, Kill running pgAdmins and launch the browser to access
>>>> them. There is a lot of interesting websites that talk about this, and how
>>>> to develop. I had to download one to have a docker indicator..... But as I
>>>> said in a previous thread, I believe that this should be a 3rd party
>>>> application and not a first class citizen on pgAdmin, as the majority of
>>>> the ones that I found are.
>>>>
>>>
>>> I can't comment on the specific ways to sort it out, but I think
>>> *basing* things in option 2 is by far the best option. If it's just an
>>> additional add-on that can be made a dependency of the packages it's not a
>>> huge problem (provided this add-on is available on the major platforms like
>>> rhel, ubuntu, debian of course)
>>>
>>
>> It would just be a modified version of what we have. Instead of having an
>> icon in the system tray, we'd probably have multiple Start Menu icons to
>> replace the tray icon menu. They would have to signal a running instance to
>> do something, or become a new instance and then do the something if nothing
>> is running already.
>>
>
> Of course, another option here might be to figure out that we're running
> under Gnome/GTK at runtime, and if so, create an indicator icon and menu
> instead of the tray icon. That is, apparently, what Skype and other similar
> apps do now. The indicator icons go on the right of the top menu bar (kinda
> like where tray icons go on macOS).
>
I investigated this, and have failed to find anything about how to do this
so far.
However, the following does fix the problem:
1) # dnf install gnome-shell-extension-topicons-plus
2) Run gnome-tweak-tool
3) Enable TopIcons Plus
There are apparently ways to enable the extension globally from the command
line. Need to test that (and figure out if it would be considered bad form
to do so).
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Showstopper desktop runtime issue
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:48 ` Re: Showstopper desktop runtime issue Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Re: Showstopper desktop runtime issue Joao De Almeida Pereira <[email protected]>
2018-03-22 16:17 ` Re: Showstopper desktop runtime issue Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Re: Showstopper desktop runtime issue Dave Page <[email protected]>
@ 2018-03-23 10:08 ` Magnus Hagander <[email protected]>
2 siblings, 0 replies; 16+ messages in thread
From: Magnus Hagander @ 2018-03-23 10:08 UTC (permalink / raw)
To: Dave Page <[email protected]>; +Cc: Joao De Almeida Pereira <[email protected]>; Murtuza Zabuawala <[email protected]>; pgadmin-hackers; Akshay Joshi <[email protected]>; Neel Patel <[email protected]>; Ashesh Vashi <[email protected]>; Robert Eckhardt <[email protected]>
On Thu, Mar 22, 2018 at 5:28 PM, Dave Page <[email protected]> wrote:
>
>>
>> 3) Electron
>>>
>>> Pros:
>>> - Full Javascript runtime, no more C++ code to handle
>>> - Self packaging for all the environments
>>> Cons:
>>> - No fully supported on Linux based OS with old libstdc++, (This might
>>> solve the problem: https://github.com/mattermost/desktop/issues/312)
>>>
>>
>>
>> Losing support for things like RHEL6 would make it completely unworkable
>> for several of my largest customers. Particularly in large enterprise
>> organisations, this would be a very substantial issue.
>>
>
> That's good to know. There are clunky workarounds (shipping different
> libcs for example, but that potentially adds licensing issues).
>
> Sidenote: It would only be an issue for desktop mode. Web mode should not
> be affected.
>
Right.
> - CPU/RAM high utilization (Found a issues around and the majority of them
>>> have solutions like CSS animations running or settings on the created
>>> windows)
>>>
>>
>> This does sound bad. But do we actually know if this is worse in Electron
>> than it is in the option #2? I mean sure, we point to things like Slack,
>> but that may not be because of electron, it may be because the app running
>> inside it?
>>
>
> We don't know for sure, but we do know that Chrome in general is a bit of
> a hog. It's certainly not a stretch to think a combination of those things
> are why people (correctly) see browser based apps as being more resource
> hungry.
>
It is, but is it more of a hog than other modern browsers? :) (I mean,
every single Electron app I've ever used has been absolutely horrible from
a CPU/RAM/Battery utilization, to the point that I've deleted them all, but
blame needs to be assigned to the right place)
> - Electron does not support tabs by default, only HTML tabs
>>>
>>
>> I think that also makes it a showstopper. This was another one of the
>> main complaints I have personally heard from people going from pgadmin3 ->
>> pgadmin4, and enough to make people not want to use it at all. It would be
>> really bad to go back to that.
>>
>
> To clarify; it would mean no tabs, but not single window. That was already
> working in the PoC. In other words, helpfiles, the debugger and query tools
> could all be opened in new windows, just not tabs on the same window that
> could be docked and un-docked.
>
> I suspect for most people that would be enough.
>
What people want, in my experience, is it for different queries. Haven't
really seen requests for it when it comes to anything other than that. But
people do definitely want the ability to do those both in tabs and in
windows, by their choice, if at all possible.
3) Electron can to play, first when we though about removing QTWebkit,
>>> because it always packs a browser with it and also and there is a very big
>>> Open Source Community being it. It came back again when when we saw that we
>>> were ready to ditch the browser. (As a personal note I dislike applications
>>> that I install in my machine and pop browser open to do anything, this is a
>>> personal issue that I would like to see if it was shared by others that was
>>> why we decided to park Electron for a second time. Because if our users are
>>> ok with it there is no need to add extra complexity to the product)
>>> The most interesting thing about the cons that I found in Electron there
>>> is an issue open for them and a bunch of different solutions to try to
>>> handle it, or even advises on how to handle it. This option also allow us
>>> to focus less on browser compatibility as the main target of our
>>> development will become Chromium which is the base of browsers like UC
>>> Browser, Vivaldi, Opera, Google Chrome.
>>>
>>
>> Please don't ever give up browser independence for the *web* version of
>> pgadmin. Don't be That Project (TM).
>>
>
> Not on my watch!
>
:)
(And don't give up on proper tabs either, but I'm sure Electron might catch
>> up in that eventually -- and the issue around RHEL6 will also go away
>> eventually)
>>
>
> RHEL 6 is in support until 2024, though it's already halfway through the
> maintenance 2 phase. It's definitely going, but we really don't know how
> many folks might still be using it in production on systems they're
> updating and using pgAdmin on. That last bit is important; many folks will
> continue to run production servers on RHEL/CentOS 6 for years, but how many
> are using them for client-side stuff or actively updating things like
> pgAdmin on them?
>
I doubt RHEL will very much be used on desktop systems all the way until
2024. But definitely still is in my experience, but it won't be used *that*
long. I still see it, but it's starting to go away, but it's the usual case
of large enterprises shifting platform and needing to certify a gazillion
little desktop apps and hardware gizmos before they can move...
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2018-03-23 12:00 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-03-22 09:49 Showstopper desktop runtime issue Dave Page <[email protected]>
2018-03-22 10:05 ` Akshay Joshi <[email protected]>
2018-03-22 10:19 ` Neel Patel <[email protected]>
2018-03-22 10:22 ` Dave Page <[email protected]>
2018-03-22 10:48 ` Murtuza Zabuawala <[email protected]>
2018-03-22 14:57 ` Joao De Almeida Pereira <[email protected]>
2018-03-22 16:14 ` Dave Page <[email protected]>
2018-03-22 16:17 ` Magnus Hagander <[email protected]>
2018-03-22 16:28 ` Dave Page <[email protected]>
2018-03-22 16:38 ` Robert Eckhardt <[email protected]>
2018-03-23 10:10 ` Magnus Hagander <[email protected]>
2018-03-22 16:58 ` Dave Page <[email protected]>
2018-03-22 18:27 ` Joao De Almeida Pereira <[email protected]>
2018-03-23 11:27 ` Dave Page <[email protected]>
2018-03-23 12:00 ` Dave Page <[email protected]>
2018-03-23 10:08 ` Magnus Hagander <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox