Il problema con gb.gui, gb.gui.opengl e gb.desktop.gnome

[vuott]

Vi riporto questa discussione avviata da Minisini sulla ailing List ufficiale:


" Hi,

I tortured my pour brain for days to find a way to solve the packaging
problem generated by the gb.gui, gb.gui.opengl and gb.destkop.gnome
components.

Here is what I suggest:

1) A gambas3-kde-support package to support all Qt4-based desktops. It
will depend on gb.qt4 and gb.qt4.opengl packages.

2) A gambas3-gnome-support package to support all other desktops. It
will depend on gb.gtk, gb.gtk.opengl and gb.desktop.gnome packages.

3) When making a package of a project named 'foo' that depends on
gb.gui, the IDE wizard will generate 'foo.deb' (I omit the version
numbers for the example) and two more packages: 'foo-kde-support' and
'foo-gnome-support'. 'foo-kde-support' will depend on 'foo' and
'gambas3-kde-support'. 'foo-gnome-support'... well you can guess.

4) No explicit dependency on 'gb.gui', 'gb.gui.opengl' then.

5) I'm not sure if adding '-support' to the package names is necessary.

6) As for components having "drivers", i.e. 'gb.db' and 'gb.compress',
something similar could be made.

What do you think about that? Did I forget anything?

--
Benoît Minisini "


" If creating gambas3-*-support is a problem, I can add the explicit
dependencies directly in the foo-*-support packages. It avoids the need
of creating new packages in the specifications.

--
Benoît Minisini "

[vuott]

...continua...


" gambas3 need kde for build and run? why a specific name cited a
desktop particulary?

PICCORO McKAY Lenz "


" This is just an example. I have to choose a name, but it must be short.
I can't put "gambas3-support-for-qt4-based-desktops" and
"gambas3-support-for-gtk-based-desktops" as package name. :-)

--
Benoît Minisini "


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

--
Benoît Minisini "


" (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?

(btw: I wish there was a gb.gtk.webkit!)

--
Bruce "


" >
> 4) No explicit dependency on 'gb.gui', 'gb.gui.opengl' then.
I don't think this is necessary.
if gambas3-gb-gui depends on gambas3-gb-gtk OR gambas3-gb-qt4, apt-get
will not pick one at random [which is what I think Krisztian was
saying]: it will pick the one that can be installed according to their
dependencies: gambas3-gb-gtk depends on the GTK libraries and
gambas3-gb-qt4 depends on the Qt4 libraries.

I will compile some packages with this and run some experiments to see
if this does actually work.

Ian "


" Circular dependencies are not allowed. So if 'foo' depend on 'foo-gtk |
foo-qt4', the 'foo-gtk' and 'foo-qt4' are not depend on 'foo'. And that
would be good. Because 'foo' doesn't work without 'foo-gtk' or
'foo-qt4', but they are metapackages (that said, confusing to install
anything). The other problem, 'foo' application doesn't work on KDE
desktop with 'foo-gtk', and doesn't work on GNOME desktop with
'foo-qt4'. The selector component doesn't work well.

> I will compile some packages with this and run some experiments to see
> if this does actually work.
>
> Ian
>
Yeah, but 'gambas3-gb-gui' is a non-existing package. See in the
packaging specifications.

Kende Krisztián "


" > (Purely theoretical given this is all a bit too hard for me)
>
> a) where is gb.image going to live?

What's the problem with gb.image?

> 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?
No: installing foo-gtk will install the gb.gtk component and GTK+ 2. But
the program will work on KDE, exactly like any other GTK+ 2 program.

> c) BTW I'll check again, but I seem to recall that the keyring is still
> there in gtk 3....
>
I'm almost sure that it has a new design. But the only important thing
is having a command-line tool to deal with it.

--
Benoît Minisini
"


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


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

--
Benoît Minisini "

[vuott]

...continua...


" > What are you talking about?
>

I don't see it. I created a Gambas project with 'gb.gui', and this not
starting on GNOME desktop without 'gb.gtk' component. 'gb.qt4' is
installed on system, but 'gb.gui' not selecting this.

kendek@Kendek:~$ locate gb.qt4
/usr/lib/gambas3/gb.qt4.component
/usr/lib/gambas3/gb.qt4.so
/usr/lib/gambas3/gb.qt4.so.0
/usr/lib/gambas3/gb.qt4.so.0.0.0
/usr/share/gambas3/info/gb.qt4.info
/usr/share/gambas3/info/gb.qt4.list

kendek@Kendek:~$ '/home/alma/alma.gambas'
gb.gui: unable to load 'gb.gtk' component
ERROR: #2: Cannot load class 'ButtonBox': Cannot load parent class:
Cannot load class 'UserControl': Unable to load class file

alma.desktop uses gb.image, gb.gui and gb.form components


So, alma.gambas (example project) uses gb.image, gb.gui and gb.form
components. :-)

Kende Krisztián "


" > Circular dependencies are not allowed. So if 'foo' depend on 'foo-gtk |
> foo-qt4', the 'foo-gtk' and 'foo-qt4' are not depend on 'foo'. And that
> would be good. Because 'foo' doesn't work without 'foo-gtk' or
> 'foo-qt4', but they are metapackages (that said, confusing to install
> anything).

Ha. ok.

> The other problem, 'foo' application doesn't work on KDE
> desktop with 'foo-gtk', and doesn't work on GNOME desktop with 'foo-qt4'.
Of course they work. If you install 'foo-gtk' on KDE, you will just run
the 'foo' program using the GTK+ libraries.

> The selector component doesn't work well.

What are you talking about?


> alma.desktop uses gb.image, gb.gui and gb.form components
>
OK, you want 'gb.gui' to use 'gb.qt4' if 'gb.gtk' is not present?

This is possible, this is something to fix in the gb.gui source code.

But this is not related to the packaging at all!

--
Benoît Minisini "


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

--
Bruce "


" > But this is not related to the packaging at all!
>

Yes, I want this. And vice versa. 'gb.gui' use 'gb.gtk' if 'gb.qt4' is
not present.
But yes, is related. Because users don't start the applications with the
current packaging specifications.

Kende Krisztián "


" OK, this is done in revision #5925.

Regards,

--
Benoît Minisini "