-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
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. |
Hi @ruimalheiro. Thanks for your efforts. Will take a look at it this week! |
Feel free to pop into the hipchat dev room and let us know about your intentions as well! |
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. |
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. |
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? |
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 "
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."
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. |
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. |
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! |
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. |
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. |
Yeah, since we can't rely on Python being preinstalled, I would see this Also, worth noting that we should be able to reuse a substantial portion of
|
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? |
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. |
Thanks for testing @EdDixon ! 👍 |
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:
@jamalex @aronasorman @EdDixon @benjaoming @MCGallaspy
Let me know what you guys think and if you guys have any problem to run the demo.
The text was updated successfully, but these errors were encountered: