Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build the Windows Installer and the Windows GUI fully in Python using wxPython Phoenix #248

Open
ruimalheiro opened this issue Oct 31, 2015 · 16 comments
Assignees
Labels

Comments

@ruimalheiro
Copy link
Contributor

I started playing around with wxPython and it seems to be a nice tool if you want to work with win32 API without having to go through all the trouble of that weird C/C++ design of win32 API.

I have built the following demo that mimics the KA Lite GUI (Tray menu) and it seems to work pretty well: Demo

To try it out, just download the repo and run "main.py". If you don't have wx installed, it will be downloaded and installed automatically by pip.

Interesting links on wxPython:

Possible benefits:

  • I think it offers everything needed to build the installer and leave INNO setup behind;
  • No need to pack the GUI and to use Visual Studio. However, the gui will be a python script, instead of a binary, so it will obviously require Python to run;

@jamalex @aronasorman @EdDixon @benjaoming @MCGallaspy
Let me know what you guys think and if you guys have any problem to run the demo.

@benjaoming
Copy link
Contributor

Hi @ruimalheiro!

We're making grounds in terms of using a Makefile for the build process and getting Bamboo to do everything for us, so I would think this is a great benefit if the whole Visual Studio packaging could be abandoned!! Great timing for this!!

You Windows people should definitely make the call for the graphics toolset for the Windows platform :) And having a Python-based toolset would make it more maintainable. Have you considered gtk3, which is also available for Windows?

This is what I've been basing the Linux GTK control panel on...

http://ka-lite-gtk.readthedocs.org/

It's built with Glade, which is great :)

Haven't done anything for the notification area yet, but such decision would be easier to design for if there was either a decision against or for cross-platform compat.

@MCGallaspy MCGallaspy self-assigned this Nov 2, 2015
@MCGallaspy
Copy link
Contributor

Hi @ruimalheiro. Thanks for your efforts. Will take a look at it this week!

@MCGallaspy
Copy link
Contributor

Feel free to pop into the hipchat dev room and let us know about your intentions as well!

@ruimalheiro
Copy link
Contributor Author

Hi @benjaoming and @MCGallaspy ! Have you tried the DEMO?

@benjaoming Thank you for your feedback. GTK3 looks great! Thanks for sharing. Something we can explore for sure if there is good support for windows.

@MCGallaspy Looking forward for your feedback! My idea is to discontinue the C/C++ version of the GUI and the use of Inno Compiler. Building both the installer and the GUI using wxPython Phoenix or GTK3 would be much better and easier to maintain.

@MCGallaspy
Copy link
Contributor

Hi @ruimalheiro. I like your idea, but a few comments:

We're trying to maintain high standards for code that we include in our official repos. Though our standards are not totally concrete right now, at a minimum we'd like code to be well-planned, well-tested, and well-commented. The best way to achieve this is to actively engage with the dev team through the entire dev process with some combination of hipchat, email, and github issues. It's unlikely that we'll merge substantial changes to the codebase without that engagement.

That said, I do like the idea of a Python-based tasktray program (especially if it's x-platform). I'd like to encourage contributors to our org's projects, and I encourage you to continue to develop this as an alternative to the existing tasktray program. The first step to engage the dev team would be to document the goals and planned features of this project, and share it for review.

@MCGallaspy
Copy link
Contributor

It's also not clear to me that this will replace InnoSetup -- in a addition to distributing the tasktray program, we use IS to distribute a python interpreter and handle some upgrade tasks. Does this project propose to replace those elements of the IS program as well?

@ruimalheiro
Copy link
Contributor Author

Hi @MCGallaspy . This is just an idea.

The purpose of this topic was simply to expose the possibility of writing both the installer and the GUI fully in python, using wxPython.

"It's also not clear to me that this will replace InnoSetup "

  • We can design and develop the installer, replacing the need to use Inno. wxPython offers all the widgets that we may need. Please take a look at the gallery above.

The demo is the GUI only.

"Though our standards are not totally concrete right now, at a minimum we'd like code to be well-planned, well-tested, and well-commented."

  • Note: This is far from final code. What I intended was for you guys to run it. Not to review it.

If you guys think it is worth trying, just let me know, so I can show something more concrete. But before moving further, I need to know if you agree with the use of wxPython.

@MCGallaspy
Copy link
Contributor

But before moving further, I need to know if you agree with the use of wxPython.

It's premature to ask whether we should use a particular library or not prior to determining the goals and design of the project. Do you want to replace the whole windows installer? Then let's think up a fully-conceived specification first, instead of creating something ad-hoc. I won't agree to use wxPython or any library prior to that.

That said, right now creating a new windows installer is not a high priority for the dev team, so I doubt we'll be able to take a lead role in the design. But we're more than happy to assist you if you want to take it on yourself! It would certainly be a big help to us! Email the team or jump into hipchat to discuss in more detail.

@ruimalheiro
Copy link
Contributor Author

Hi @MCGallaspy

Yeah, I see what you mean and you are right. Well, I'll have to make room for some time and discuss that with you all to explain my goal with this.

In the meantime, you are doing a great job maintaining the current INNO / C++ and that is also great.

Thank you for the feedback!

@benjaoming
Copy link
Contributor

I very much agree with both @ruimalheiro's innitiative and @MCGallaspy 's precaution -- it would be great to have the build process made as simple (unified) as possible. The long-term goal should be to have a very solid KA Lite that won't take resources from Kolibri development, but can still be improved and maintained either by FLE or the community! If either of these don't have to bother much with highly complex build setups, it's more likely that future releases will find their way and KA Lite can continue to be of value (mainly for existing deployments).

I don't know the complexity of creating a new UI, but since a pure-python UI is a precondition for a simpler build process, it might be possible to do this without investigating the builder... but we really do have to want to invest in the creation of a new build process, then.

I had to fake the kalite prackage and data to start a less heavy experimentation with the Debian installer -- perhaps this method would also be relevant for other platforms.

@benjaoming
Copy link
Contributor

Also; I've detached ka-lite-gtk from ka-lite to have freedom from the heavy Debian packages and to be able to maintain it outside of the KA Lite release cycle. This could also be a good way to get a wxPython up and running, released, and tested quickly once the Windows installer starts installing ka-lite through setuptools.

@jamalex
Copy link
Member

jamalex commented Nov 7, 2015

Yeah, since we can't rely on Python being preinstalled, I would see this
working best for the launcher GUI, rather than the installer itself.
Luckily, Inno builds fine in Wine; it's the VS launcher GUI that's more
complicated to build, so this could be a good match.

Also, worth noting that we should be able to reuse a substantial portion of
the code for the installers for Kolibri.
On Nov 7, 2015 1:10 PM, "benjaoming" [email protected] wrote:

Also; I've detached ka-lite-gtk from ka-lite to have freedom from the
heavy Debian packages and to be able to maintain it outside of the KA Lite
release cycle. This could also be a good way to get a wxPython up and
running, released, and tested quickly once the Windows installer starts
installing ka-lite through setuptools.


Reply to this email directly or view it on GitHub
#248 (comment)
.

@ruimalheiro
Copy link
Contributor Author

Yeah, I think that is a good point. Building the GUI in Python would be a great help. The demo is basically a KA Lite GUI.

By using this, we won't need to pack a compiled GUI and it will be built automatically, when the installer is built.

wxPython is cross-platform but I don't know if the tray icon is supported under osx and linux. If I'm not mistaken, there is already some work in a GUI for OSX right?

@cpauya
Copy link
Contributor

cpauya commented Nov 11, 2015

Yes @ruimalheiro, we've been maintaining the GUI for OS X since v0.14.x. We haven't tried testing wxPython on OS X yet, so hope to get our hands on it later too.

@EdDixon
Copy link

EdDixon commented Jan 28, 2016

Just tried the demo here on win32 XP and it is a really fast clean solution replacing our current win32 binary? I really like it!

2016-01-27_20-43-39

@ruimalheiro
Copy link
Contributor Author

Thanks for testing @EdDixon ! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants