Re: [gedit-list] Gedit Plugins - Unofficial Enhancement Proposal
- From: chuchi <jbarbero quiter com>
- To: gedit-list <gedit-list gnome org>
- Subject: Re: [gedit-list] Gedit Plugins - Unofficial Enhancement Proposal
- Date: Fri, 23 Feb 2007 09:34:15 +0100
Nice study Zeth,
I agree with Dudus in these points but the idea of easy plugin installation is a very good idea.
El vie, 23-02-2007 a las 03:26 -0200, dudus escribió:
This is very good spec from my point of view. Easy to implement and
gedit will have good benefits.
The best benefit I see is that it will be easier to use so people will
search more plugins so people will write more plugins.
But I don't agre with itemms 2 & 5.
2. It would be good to have a plugin folder where you put plugins that
will be available system wide. This way administrator can deploy
plugins to all users.
5. Firefox comes with no extensions to simplify usage and avoid
keeping it bloated with features one will rarely need. I mean Firebug
is a must have for me but mom doesn't share that. When they see an
extensions is too good to be kept from core they incorpore that on
firefox. Firefox2 got session management and better tab handling
through existing extensions on firefox1.5.
In Gedit SpellCheck and FileBrowser are plugins, while they implement
features that should be on core.I'm not sure why this is done this
way, maybe because it's easier to do so. While it doesn't happen it's
good to have them as default installed extensions.
But you're probably right , important plugins should be on core and
the other ones should out of Gedit by default
On 2/22/07, Zeth Green <theology gmail com> wrote:
> Hello Everyone,
>
> This is an unofficial enhancement proposal, I am not a Gedit
> developer, I am just a keen user who has started to write plugins.
> Please do discuss this and add your improvements. These changes will
> require some very minor code changes to gedit, but I hope you will
> agree that it would be well worth it.
>
> Rationale
> =========
>
> Extensions are the killer feature of Firefox. Indeed the vibrant
> extension community is one of the major reasons why people use Firefox
> over the otherwise more beautiful Epiphany. Indeed, some GNOME-based
> distributions (such as Ubuntu) do not even come with Epiphany any
> more.
>
> Gedit plugins do not have the same buzz as Firefox extensions. Of
> course, Firefox is a very big project. However, there is more to it
> than that, after all, almost every GNOME user gets Gedit.
>
> The truth is that very few Gedit users install plugins, for two
> reasons. Firstly, there are not that many plugins, there is not a
> vibrant scene yet. Secondly, and most fundamentally, it is just too
> complicated to install plugins.
>
> The plugin architecture of Gedit is very nice for people like me who
> want to write Gedit plugins, however it is frankly horrific for the
> end-user to install them, especially if they are new to Linux. If one
> has to use the command-line to install a plugin, then the user might
> as well use Emacs.
>
> In this document, I will outline how I feel that Gedit's approach to
> plugins can be improved, to make the plugins far more user friendly
> and inclusive, as well as encouraging the plugin scene to be far more
> vibrant.
>
>
> Proposals in brief:
> ===================
>
> 1. Single and Simplified plugin format.
>
> 2. Single plugin location.
>
> 3. New Button - "Install New Plugin".
>
> 4. New context menu item - "Delete Plugin".
>
> 5. No bundled plugins.
>
>
> Proposals:
> =========
>
> 1. Single Plugin Format
>
> All plugins have a .gedit-plugin file. However, beyond that, at the
> moment, plugins can be organised in two ways. They can be a single
> file, or they can be a directory. This inconsistency will make it very
> complicated for graphical plugin installation and especially
> uninstallation.
>
> I propose a single format. All plugins will basically follow the
> directory approach, but the gedit-plugin file will be inside the
> directory.
>
> Each plugin must be provided for download as a gzipped directory, e.g.
> plugin.tar.gz. The archive contains the directory, which then contains
> all the files.
>
> This will make graphical installation and uninstallation very simple.
> It will also have benefits for command-line users, each installed
> plugin is a directory. To delete the plugin, just delete the
> directory.
>
> This will require no code changes to existing plugins, they will just
> need to be re-archived. I could repackage all existing plugins in an
> hour.
>
> 2. Single Plugin Location
>
> It is too confusing for the user to have more than one plugin
> location. I am proposing that there will now only be one place to
> install plugins. I.e. ~/.gnome2/gedit/plugins
>
> 3. New Button - "Install New Plugin".
>
> The current plugin manager is quite user friendly but is missing the
> ability to add plugins. You can activate and deactivate, but you
> cannot install or uninstall plugins.
>
> So we need a new button - "Install New Plugin". Clicking this button
> would then open the file browser, expecting a .tar.gz.
>
> The user then browses to where they have downloaded a new plugin. When
> the file is selected and the user presses OK, the selected file will
> be ungzipped, and the directory inside will be copied into the plugin
> directory.
>
> At this point the plugin can be activated and deactivated using the
> checkbox in the normal way.
>
> 4. New context menu item - "Delete Plugin".
>
> Currently, when you right click on a plugin in the manager, you
> receive a context menu. I am proposing a new menu item called "Delete
> Plugin". This will delete the directory of that plugin.
>
> 5. No bundled plugins.
>
> Firefox does not come with a large number of pre-installed plugins.
> Even though most Firefox plugins are very small files. Why? Because
> they do not want to crowd out the extensions scene with 'official
> extensions'. Instead, what was once core functionality in the old
> Mozilla, now shares the same website with every other plugin.
>
> I am proposing that all the currently bundled plugins, and those of
> the extra plugins pack, be incorporated into a new plugins website.
> The fact that end users are coming to the site to get these plugins,
> would encourage them to try out others, as well as allow them to learn
> how to install plugins. I think this proposal would do the most to
> encourage the development of new plugins, and help expand the plugin
> community to a sustainable size.
>
> Thankyou for reading. Please let me know what you think.
>
> Best Wishes,
> Zeth
> _______________________________________________
> gedit-list mailing list
> gedit-list gnome org
> http://mail.gnome.org/mailman/listinfo/gedit-list
>
--
Eduardo Cereto Carvalho <eduardo cereto net>
http://cereto.net/
"Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm"
|
Jesús Barbero Rodríguez
Departamento de Análisis y Programación - Desarrollo tecnológico
Zoco Gran Santander, 1ª Planta ■ 39011 Peñacastillo ■ Santander ■ ESPAÑA
Tel.: +34 902 233 323 ■ Fax: +34 902 234 280
|
AVISO LEGAL: Este mensaje contiene información destinada exclusivamente al usuario de destino, pudiendo contener información confidencial o protegida legalmente. Si, por un error de envío o transmisión, ha recibido este mensaje y usted no es el destinatario del mismo, por favor, notifique de este hecho al remitente y no use, informe, distribuya, imprima, copie o difunda este mensaje bajo ningún medio . Cualquier opinión en él contenida, es exclusiva de su autor y no representa necesariamente la opinión de Quiter Servicios Informáticos, S.L.
LEGAL WARNING: This e-mail and any attachment, contain information intended solely for the addressee and may contain confidential information or legally protected data. If you are not the intended recipient, please notify the sender and do not use, disclose, distribute, copy, print or rely on this e-mail under any circumstances. The views and opinions expressed are the authorŽs own and do not necessarily reflect those of Quiter Servicios Informáticos, S.L.
|
|
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]