On Thu, Nov 13, 2008 at 07:05:48PM +0200, مؤيد السعدي wrote: > > I designed the liveusb creator in a way that makes it very easy to throw > > any GUI on top of it. I initially started writing a PyGTK gui, but > > switched to PyQt because: 1) The implementation turned out to be much > > cleaner and 2) It ran great out of the box on Windows. > > > yes, you have done good job, but it's different use case > I'm not making a replacement to livecd-creator > I love the windows port, and KDE livecd may love the qt port > > > The liveusb.creator module already does all of the hard work for you, > > and wrapping a GUI around it is quite easy. You can find the latest > > liveusb-creator API documentation here: > > > > http://lmacken.fedorapeople.org/liveusb-creator/api/ > > > thanks, I'll use that when I'm done with the GUI design > > > Now, in order to be the 'default' liveusb-creator GUI, it needs to be > > fully feature compliant (to the extent that the liveusb.creator module > > currently is), and it needs to run on Windows. If the GTK > > implementation can meet those requirements, then I would be fine with > > making it the default; assuming that the implementation is as > > clean as the current, and is easily maintainable. > > then I don't want it to be the default > I want to satisfy my ojuba.org users > http://fedoraproject.org/wiki/DerivedDistributions/LiveCDs#Ojuba_Linux
Ok, that's fine with me. > as we used to have a howto for making a liveusb using the your > liveusb-creator on windows > and another one using the livecd-iso-to-disk in linux (from within the > livecd on the fly) > but we get this question why the linux tool is cli > and our livecd is already overburned (as we ship OpenOffice.org) > there is no place for pyqt and even with that there is no way to set the > source to be the CD device (/dev/sr0) > > as I said I would love to see it beside > >> liveusb-creator (API) and liveusb-creator-qt (and maybe adding > liveusb-creator-cli) > and make the API and the cli pleasing to add feature more than the current > bash script > livecd-iso-to-disk > so that Jermey find it fun and pleasing to add his new feature there Yeah, I started working on the cli version, but I'm not sure if I ever got a chance to finish it. It shouldn't be very difficult to polish up. The API is currently pretty clean, and it is quite easy to add new features. The liveusb-creator is lagging a little bit behind of the livecd-iso-to-disk in terms of features, mainly because I don't have time to constantly port Jeremy's changes :) > > As far as GTK is concerned, the current liveusb-creator is actually > > rendered with GTK widgets on a Fedora 10 GNOME desktop, thanks to > > QGtkStyle. So, I guess the only reason for creating a brand new > > interface from scratch is to avoid the PyQt dependency on livecds? That > > doesn't exactly sounds like the best reason for re-implementing the > > interface, but if someone is willing to write the code, I'm not > > complaining ;) > > > yes it's, the dependency and the on-the-fly issue Understandable; I think your interface will be a valuable asset to the live media in that case. > > Here are some prototypes of what the next major release of the > > liveusb-creator will probably look like: > > > http://lmacken.fedorapeople.org/liveusb-creator/liveusb-creator-tabbed-0.png > > > http://lmacken.fedorapeople.org/liveusb-creator/liveusb-creator-tabbed-1.png > > > http://lmacken.fedorapeople.org/liveusb-creator/liveusb-creator-tabbed-2.png > > > not good for my use case > 1. no way to do on the fly ie. no iso and no download > 2. my users don't like to see the logs (which takes half of the window) > 3. my users thinks that tabs are used for independent things, not for steps > 4. my users want things to just work ie. if they just click OK without > thinking it should work Opening the program and clicking "Create LiveUSB" will Just Work, as it auto-detects all of the hardware, and defaults to downloading the ISO. But yes, I understand your use case, and I think the liveusb-creator is definitely capable of supporting it. > 5. valid values for tab #2 are taken from tab #3 (the max value for the > size of home or persistent layer can't be more than the free space on > target [on tab#3] minus the size of the iso) Yeah true. As I said before, that is merely a non-functioning prototype at the moment. I'm completely open to suggestions/improvements/criticism/patches/etc. > ok, let me tell you how it work > I used hal to get the list of usable target partitions > I used hal to set the source device (/dev/sr0) > so when the user runs it, he just plug his usb pen and it will be selected > automatically as target > and when he inserts the CD it will just chosen as source (and if he is > running the livecd it will already be selected), without any interaction Yep, the liveusb.creator module currently has support for auto-detecting usb keys from HAL via DBus, and monitors add/remove device events so it can populate that field on-the-fly when someone plugs their USB stick in. As far as CD support, there is nothing there to handle that at the moment, but I think it would be a great addition. > all advanced features are hidden in side the expander > [the only thing I'm looking for is away to guess if a system is an XO or an > intel MAC > some people suggested checking for PCI ids that exists only in intel macs] > > > Let me know if you have any questions, and please keep me in the loop on > > the progress! There is also a liveusb-creator mailing list where we can > > discuss further implementation details. > > > > Cheers, > > > > luke > > I would love to be there > I'm moving the rest of the talk there then Sounds good. Cheers, luke -- Fedora-livecd-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-livecd-list
