[Fedora-livecd-list] liveusb-creator-gtk to be included on livecds

[مؤيد السعدي]

hi,
> 1) Make the UI similar to the existing liveusb-creator
no need each one have different use cases
the current qt liveusb-creator is amid to be used on an installed system
(eg. windows)
that's why having a download feature is something good

while liveusb-creator-gtk is aimed to be shipped in the livecd
and it should work on the livecd without having the iso and without
downloading it

> 2) Talk to existing developers about merging the code or package it
separately in Fedora
here and in the IRC
> 3) Use glade. Hard coding things might be easier for you but it certainly
isn't for others working on the codebase. Rahul 
they are not hard coded, adding new options is very simple, you just add
them to the array in the form of
('id','title', 'tooltip', default_value)
I think this is much better than glade, much easer for the future and much
easer to code

> 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

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

> 
> 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

> 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
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)

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

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