liveusb-creator-gtk to be included on livecds

hi,
as I said on the IRC, I'm going to make a pyGTK tool to install the livecd
into a usb pendrive

I'm releasing it under GPLv2 to allow fedora shipping it with their rpms

What I have done so far is the GUI which automatically know source cds and
target partitions from dbus (no refresh button as it sense the change)

all options and we can add more at any time as I made them a python dict

the header is a gtk.Label() surrounded by two icons
the fedora/ojuba/gnome logo by using start-here icon name (to make branding
easy)
and drive-removable-media-usb icon name (from gnome icon theme)

I want to make sure that those icons are suitable for the KDE/XFCE/LXDE
spins

I did not implement the real creation of the livecd yet, simply because I
don't want to reinvent the wheel
I guess that would be 10 lines to code after we split liveusb-creator into
liveusb-creator and liveusb-creator-qt (and maybe adding
liveusb-creator-cli)

I need to do small changes 
like to add tooltips and gettext 
to make the min and max values of layer size to be read from dbus or to set
it at a sane default

I'm think about "all" checkbox beside target device that is display all
devices not only usb devices

so any suggestion

[Bryan Kearney]

مؤيد السعدي wrote:
>  hi,
>  as I said on the IRC, I'm going to make a pyGTK tool to install the livecd
>  into a usb pendrive 
How is this different from https://fedorahosted.org/liveusb-creator/

-- bk

[Stewart Adam]

On 11/12/08 6:46 AM, مؤيد السعدي wrote:
>  I'm think about "all" checkbox beside target device
> that is display all
>  devices not only usb devices
>
>  so any suggestion 
Hi,

I think that including this on the Live CD is a great idea (although 
offtopic for this list, it would be great if it was included in the default 
Desktop install as well).

The program features look great, but I think the UI is a bit too busy. I 
would recommend making the Live USB icon's transparent, setting a 6px border 
width on the main window and using 6px spacing between vertical elements and 
12px between horizontal spacing. Perhaps there should also add a "Help" 
button on the left which would open a web browser and open a short guide to 
using the program on the Fedora wiki or something.

Would you be interested in using Glade for the GTK+ interface? I'd be 
willing to help create a glade file and I can provide some sample code that 
will make accessing the widgets very easy (self.ui.widgetname), as well as 
enabling i18n for the entire program.

Stewart

>  How is this different from https://fedorahosted.org/liveusb-creator/
>   
that can't be included in my livecd because it depends on QT (ten MB at
least)
but a gtk version will be a plus because pygtk is already installed in
almost all livecds

it's a matter of 9KB

>  
>  I think that including this on the Live CD is a great idea (although
>  offtopic for this list, it would be great if it was included in the
>  default
>  Desktop install as well).
>   
yes that's the point of it. at least on my Ojuba.org

>  The program features look great, but I think the UI is a bit too
> busy. I
>  would recommend making the Live USB icon's transparent, setting a 6px
>  border 
Oh! I thought that white BG give it some different look because it's a
header banner

>  width on the main window and using 6px spacing between vertical
> elements
>  and 
6px! yes it looked better, thanks

>  12px between horizontal spacing. Perhaps there should also add a
> "Help"
>  button on the left which would open a web browser and open a short guide
>  to
>  using the program on the Fedora wiki or something.
>   
maybe, I delay the documentation part for now

>  Would you be interested in using Glade for the GTK+ interface?
> I'd be
>  willing to help create a glade file and I can provide some sample code
>  that
>  will make accessing the widgets very easy (self.ui.widgetname), as well 
as
>  enabling i18n for the entire program.
>   
no thanks, I hate glade
using code like this
    for i,j,k in [('mactel',"Intel
Macs",0),('xo',"XO",0),
('xo-no-home',"No XO Home",0)]:
      self.opt[i]=gtk.CheckButton(j)
      self.opt[i].set_active(k)
      hb.pack_start(self.opt[i], False,False,0)

makes adding new options much simpler for me,
glade is aimed to make it easy, and for my case direct coding is much
easier

[Jeremy Katz]

On Wed, 2008-11-12 at 18:12 +0200, مؤيد السعدي wrote:
>  > Would you be interested in using Glade for the GTK+ interface?
> I'd be
>  > willing to help create a glade file and I can provide some sample code
>  > that
>  > will make accessing the widgets very easy (self.ui.widgetname), as well
>  as
>  > enabling i18n for the entire program.
>  > 
>  no thanks, I hate glade
>  using code like this
>      for i,j,k in [('mactel',"Intel
> Macs",0),('xo',"XO",0),
>  ('xo-no-home',"No XO Home",0)]:
>        self.opt[i]=gtk.CheckButton(j)
>        self.opt[i].set_active(k)
>        hb.pack_start(self.opt[i], False,False,0)
>  
>  makes adding new options much simpler for me,
>  glade is aimed to make it easy, and for my case direct coding is much
>  easier 
While things like this may be easy in the short-term (I know -- been
there, done that), in the longer term it is far more maintainable to
build your UI using glade.  It will help to make things conform more
easily to the HIG and also add things over the future without requiring
major changes to the flow of the program.

Jeremy

[Rahul Sundaram]

مؤيد السعدي wrote:
>  hi,
>  as I said on the IRC, I'm going to make a pyGTK tool to install the livecd
>  into a usb pendrive
>  
>  so any suggestion 

1) Make the UI similar to the existing liveusb-creator

2) Talk to existing developers about merging the code or package it 
separately in Fedora

3) Use glade. Hard coding things might be easier for you but it 
certainly isn't for others working on the codebase.

Rahul

[Luke Macken]

On Wed, Nov 12, 2008 at 01:46:35PM +0200, مؤيد السعدي wrote:
>  hi,
>  as I said on the IRC, I'm going to make a pyGTK tool to install the livecd
>  into a usb pendrive
>  
>  I'm releasing it under GPLv2 to allow fedora shipping it with their rpms
>  
>  What I have done so far is the GUI which automatically know source cds and
>  target partitions from dbus (no refresh button as it sense the change)
>  
>  all options and we can add more at any time as I made them a python dict
>  
>  the header is a gtk.Label() surrounded by two icons
>  the fedora/ojuba/gnome logo by using start-here icon name (to make branding
>  easy)
>  and drive-removable-media-usb icon name (from gnome icon theme)
>  
>  I want to make sure that those icons are suitable for the KDE/XFCE/LXDE
>  spins
>  
>  I did not implement the real creation of the livecd yet, simply because I
>  don't want to reinvent the wheel
>  I guess that would be 10 lines to code after we split liveusb-creator into
>  liveusb-creator and liveusb-creator-qt (and maybe adding
>  liveusb-creator-cli) 
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.

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/

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.

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

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

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

[Jeremy Katz]

On Wed, 2008-11-12 at 22:07 -0500, Luke Macken wrote:
>  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?   
If you can find another 50 megs of things (size of PyQt4 + qt + qt-x11)
to remove from the live image, then we could include PyQt.  Of course,
someone else is likely to then want to use that space for several other
applications.  I think that it's unlikely that the liveusb-creator alone
is worth that much image space :-)

Jeremy

[Luke Macken]

On Wed, Nov 12, 2008 at 10:07:42PM -0500, Luke Macken wrote:
>  On Wed, Nov 12, 2008 at 01:46:35PM +0200, مؤيد السعدي wrote:
>  > hi,
>  > as I said on the IRC, I'm going to make a pyGTK tool to install the livecd
>  > into a usb pendrive
>  > 
>  > I'm releasing it under GPLv2 to allow fedora shipping it with their rpms
>  > 
>  > What I have done so far is the GUI which automatically know source cds and
>  > target partitions from dbus (no refresh button as it sense the change)
>  > 
>  > all options and we can add more at any time as I made them a python dict
>  > 
>  > the header is a gtk.Label() surrounded by two icons
>  > the fedora/ojuba/gnome logo by using start-here icon name (to make branding
>  > easy)
>  > and drive-removable-media-usb icon name (from gnome icon theme)
>  > 
>  > I want to make sure that those icons are suitable for the KDE/XFCE/LXDE
>  > spins
>  > 
>  > I did not implement the real creation of the livecd yet, simply because I
>  > don't want to reinvent the wheel
>  > I guess that would be 10 lines to code after we split liveusb-creator into
>  > liveusb-creator and liveusb-creator-qt (and maybe adding
>  > liveusb-creator-cli)
>  
>  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.
>  
>  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/
>  
>  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.
>  
>  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 ;) 
So, apparently qgtkstyle is not installed by default on F10, so the
liveusb-creator is still rendered using Qt.  I'll bring this up on
f-d-l.

>  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
>  
>  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. 
If you want, go ahead and apply for the gitliveusb-creator group[0] in fas.
That way, we can get your code under revision control, and start integrating.

luke

[0]: https://admin.fedoraproject.org/accounts/group/view/gitliveusb-creator

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

[Luke Macken]

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