gnome15-team team mailing list archive

[Brett Smith <tanktarta@xxxxxxxxxxxxxxxx>]

On Mon, 2011-04-18 at 04:55 +0200, Nuno Araujo wrote:
> Hi Brett
> 
> Below is a proposal to change the structure of the Gnome15 source tree
> that could (I think) simplify it's management.
> As you will see, this new structure goes "against" my previous proposals
> that had a tendency towards a splitting of the source tree.
> 
> Would you be kind enough to read it (I know it's a bit long) and tell me
> what you think.
> 
> If you agree with the proposal, I will make a branch to implement this
> changes. Given the time that I have available, we could target a merge
> of this branch for the Gnome15 0.8 release.
> 
> ====== Rationale ======
> Currently the Gnome15 source tree is split among several projects:
> .
> ├── g19d
> ├── gnome15
> ├── gnome15-gnome-plugins
> ├── gnome15-iconpack
> ├── gnome15-impulse15
> ├── gnome15-indicator
> ├── gnome15-kde-plugins
> ├── gnome15-panel-applet
> ├── gnome15-sandbox-plugins
> ├── gnome15-systemtray
> ├── gnome15-ubuntu
> ├── gnome15-ubuntu-plugins
> ├── lgsetled
> ├── pylibg19
> └── site
> 
> Many of these projects are deeply related with each other and the only
> advantage of this structure seems to be the fact that they make
> packagers life easier.
> 
> By using some of the "GNU Build System" features (hereafter GBS), we can
> keep this advantage and simplify the maintainers work.
> 
> ====== Implementation ======
> - Move the applet, indicator and system-tray to the gnome15 source tree.
> - Move all the icons to the gnome15 source tree.
> - Move *all* the plugins to a new gnome15-plugins project. This include
> the sandbox-plugins.
> 
> By default, all the gnome15 components would be built and installed if
> their build dependencies are available.
> User could change this behavior by passing one or more "--disable"
> arguments to configure.
> Affected components by these arguments would be:
> - applet
> - app-indicator
> - system-tray
> 
> By default, all the plugins would be installed even if the user doesn't
> have the required runtime dependencies installed.
> Exceptions to this rule are:
> - The "sandbox" plugins that would be built and installed only if a
> "--enable-sandbox-plugins" argument is passed to configure.
> - All the plugins that need the presence of some "native" libraries to
> be built (Currently the impulse15 plugin). These plugins are only built
> if the library is present on the computer doing the build.
> 
> User could change this behavior by passing one or more "--disable"
> arguments to configure (one argument available by plugin?).
> 
> Making the plugins became a "root level" project would allow to release
> new versions without having to release a new version of the "core"
> packages.
> 
> Additionally to the changes that would be necessary to the source code
> tree structure and the GBS support files (configure.ac and makefile.am),
> some changes to the application code would be required:
> - Each plugin would have a new method "is_usable" that should return
> True if the plugin can be enabled.
> This method would check among other things that the runtime dependencies
> to enable the plugin are satisfied.
> - In the "Plugins" tab of g15-config unusable plugins would be grayed
> out.
> - Somewhere in the g15-config UI we could allow the user enable the
> "notification" system and automatically select the "best" one to use
> (app-indicator, notification area...). From what I remember from when I
> used Ubuntu, this is already the case with applications like Evolution
> and Empathy.
> User could always disable the "notification" and manually add the applet
> to the panel.
> 
> Finally we would have this structure:
> .
> ├── g19d
> ├── gnome15
> │   └── src
> │       ├── gnome
> │       │   ├── applications
> │       │   ├── autostart
> │       │   └── dbus
> │       ├── main
> │       │   ├── python
> │       │   │   ├── applet
> │       │   │   ├── gnome15
> │       │   │   │   └── drivers
> │       │   │   ├── indicator
> │       │   │   └── systemtray
> │       │   └── resources
> │       │       ├── glade
> │       │       ├── icons
> │       │       │   ├── hicolor
> │       │       │   ├── AwOken
> │       │       │   ├── elementary
> │       │       │   ├── HighContrastLargePrintInverse
> │       │       │   ├── ubuntu-mono-dark
> │       │       │   └── ubuntu-mono-light
> │       │       └── images
> │       ├── man
> │       ├── scripts
> │       ├── themes
> │       ├── udev
> │       └── xcf
> ├── gnome15-plugins
> │   └── src
> │       ├── background
> │       ├── backlight
> │       ├── browser
> │       ├── cal
> │       ├── cairo-clock
> │       ├── clock
> │       ├── fx
> │       ├── g15daemon-server
> │       ├── impulse15
> │       ├── indicator-me
> │       ├── indicator-messages
> │       ├── lcdbiff
> │       ├── macro-recorder
> │       ├── macros
> │       ├── menu
> │       ├── mpris
> │       ├── nm
> │       ├── notify-lcd
> │       ├── notify-lcd2
> │       ├── panel
> │       ├── ppastats
> │       ├── processes
> │       ├── rss
> │       ├── screensaver
> │       ├── stopwatch
> │       ├── sysmon
> │       ├── ts3
> │       ├── videoplayer
> │       ├── volume
> │       ├── webcam
> │       ├── webkitbrowser
> │       ├── weather
> │       └── window-thumbnail
> ├── lgsetled
> ├── pylibg19
> └── site
> 
> 
> ====== Packaging ======
> With this new structure, packagers could then choose a packaging
> strategy that respects their distribution packaging policies.
> 
> ===== gnome15 =====
> - Package gnome15 in a single package and have some optional
> dependencies that the user can choose to install;
> - Or split gnome15 in several packages (core, app-indicator, applet,
> system-tray) and allow the user to install each of them individually.
> 
> E.g. : For Ubuntu, gnome15 would be built with the app-indicator and
> system-tray support enabled and installed by default, but applet could
> be packaged separately.
> In Arch Linux case, the default notification system installed would be
> the system-tray, and users could manually install the app-indicator.
> In both cases, since the g15-config GUI would allow user to disable the
> "notification" system, final user could always disable it and add the
> applet to the panel.
> 
> ===== gnome15-plugins =====
> - Have a single package for all the gnome15-plugins and specify
> "optional" dependencies that the user can choose to install if they want
> a full featured gnome15-plugins (Recommended);
> - Or package each plugin independently and maybe create some
> meta-packages that install related plugins together.
> 
> ===== lgsetled =====
> No changes.
> 
> ===== pylibg19 =====
> No changes.
> 
> ===== g19d =====
> No changes.
> 
> Regards
> 

Hey Nuno,

OK. Cool. I don't have a problem with any of this, as it will bring
Gnome15 more into line with how other applications are built. The number
of files to required to build from source is already too high, and I
didn't want it to go any higher. This will help with this.

One of the reasons for the way things are arranged is that I found
autotools very hard to learn ;) I tried a number of different ways of
building, but in the end it was only autotools that covered everything I
wanted to do. However, a lot of mistakes were made and I spent *way* to
much time packaging/building :(

The only other thing I want to take into account with this change is the
separation of the UI code from the service to allow a KDE front-end to
be written. Part of this would be the creation of a 'libgnome15' that
contains all the common code.

The is_usable flag in each plugin is a good idea too, this is currently
not handled at all as you know.

Off topic, preparation for 0.6.0 is now building up. I have given your
stop-watch plugin a good look over, and the only problem I found was
with a fresh installation (the default values were a bit odd). I have
already fixed this an am about to push it into trunk along with a bunch
of other Natty related fixes.