On Fri, 2013-11-01 at 10:51 +0100, Benoît Minisini wrote:
> Le 01/11/2013 02:48, Bruce a écrit :
> > On Fri, 2013-11-01 at 11:41 +1030, Bruce wrote:
> >> On Fri, 2013-11-01 at 01:44 +0100, Benoît Minisini wrote:
> >>> Hi,
> >>>
> >>> In revision #5924, the IDE generates meta-packages for QT4 and GTK+
> >>> support when a project uses the gb.gui component. There is no dependency
> >>> on the non-existing gb.gui package anymore. Same thing for gb.gui.opengl.
> >>>
> >>> So, if the 'foo' project uses gb.gui, the packager will generate the
> >>> three following packages:
> >>> - 'foo', the full project will all its dependencies.
> >>> - 'foo-qt4', a void package that depends on 'foo' and 'gb.qt4'.
> >>> - 'foo-gtk', a void package that depends on 'foo' and 'gb.gtk'.
> >>>
> >>> If 'foo' uses gb.gui.opengl, the corresponding opengl dependencies will
> >>> be added to the 'foo-qt4' and 'foo-gtk' packages.
> >>>
> >>> At the moment, only Debian/Ubuntu has been implemented.
> >>>
> >>> Can you test it and tell me if it works for you?
> >>>
> >>> I will add the conditional dependency foo-gtk | foo-qt4, but I want to
> >>> check if it possible with RPM, Arch, and Slackware packages first.
> >>>
> >>> Regards,
> >>>
> >>> P.S. I admire you and others making binary packages. Playing with debian
> >>> packaging is like programming the Win32 API with the brainfuck language
> >>> for me. It took me more than four hours to make these two metapackages
> >>> without getting a cryptic error.
> >>>
> >>
> >> (Purely theoretical given this is all a bit too hard for me)
> >>
> >> a) where is gb.image going to live?
> >> b) if 'foo' uses one of the UI's directly then I presume you would only
> >> get (say) foo-gtk. Does that render the entire package unusable on a KDE
> >> environment?
> >> c) BTW I'll check again, but I seem to recall that the keyring is still
> >> there in gtk 3....
> >>
> >
> > Another thing just popped into my head.
> >
> > If 'foo' uses gb.qt4.webkit then even if it is explicitly using gb.gui
> > then the gb.gtk component is redundant as the app will always start with
> > gb.qt4 active.
> >
> > I attached a pic to show what I mean.
> >
> > So how far does/will the packager go to resolve that only gb.qt4 is
> > required?
>
> If 'foo' uses gb.qt4.webkit, it cannot use gb.gui.
No, you missed the point. (I think)... :-) 'foo' is only designed to use
gb.gui but it depends on 'ph.auction', which because it relies on
gb.webkit must mean that:
1) the package must contain the gb.qt4 component so that the third party
component will run
2) but on the other hand, if there is something provided by gb.gui that
is internally dependant on the <<switcher>> gb.gui say some theoretical
thing called gb.gui.beaujolais then both gb.qt4 and gb.gui (and the
dreaded beaujolais components must be included.
At the moment this all works because the decision as to which gui is
used is made by the runtime. So even though 'foo' is using gb.gui
something else (ph.auction) it uses depends on and, as you implied,
restricting the application to switch to gb.qt4 with no effort on behalf
of the programmer or the user. To get a bit clearer, or perhaps even
less clear, suppose programmer "Adelie" has no idea what gui will need
to be used for 'foo2' and say for the sake of the argument that they
want to use another 3rd party component that we distribute (ph.sales)
which in turn is dependant on ph.auction. From the point of view of the
IDE, all she needs to do is use gb.gui (and ph.sales) and bingo
everything works. Mainly because the runtime resolves all this and
decides that the whole project needs to be run using the gb.qt4
component.
This is the crux. If you are talking about a packaging system that is
only going to base its' decision on what UI component to include on the
application level ('foo2'), then how do we resolve a dependency that is
(now) two levels away?
'foo2'--> 'gb.gui'
--> 'ph.sales' --> ph.auction --> gb.webkit --> gb.qt4
Adelie can't see, and indeed should not need to see, that dependency
down the chain. So, how far does the packager need to go to decide
whether or not to include/exclude a particular "desktop" (btw: I hate
that word too, it's not a desktop it's a "UI" at best or a "window
widget provider".)
As I said, purely theoretical because we distribute everything as
autotools installers not binaries. It just concerns me that somewhere
down the track an assumption could be made that would render even the
autotools packaging not-working.
>
> >
> > (btw: I wish there was a gb.gtk.webkit!)
> >
>
> Something to be done, but a big job, because the GTK+ webkit relies on
> other libraries to handle the network, whereas everything is under the
> hand with Qt4.
>
Yep, understood. But ... I can still "wish" can't I? :-)
--
Bruce <bbr...@paddys-hill.net>
Paddys-Hill dot net
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
