My understanding is, the master source of all plugins with the exception of the ones Afirvida recently added is already lxpanel. That is the tarball in which they release to users.
If you are referring to making more/all standard plugins static, that is probably a good idea. The way external plugins link against other parts of the panel causes way too much stuff to be brought into the external images and is counterproductive. I had meant to post this reply on the list already. Does it not happen when you do Reply? PCMan wrote: > I CC this mail to LXDE mailing list. > > I agree with your proposal to put only unstable or less frequently > used plugins in a separate lxpanel-plugins tree. The lxpanel-plugins > dir was created by Fred as an initial attempt to develop lxpanel > plugins outside the source tree of lxpanel itself. Some small plugins, > I think, shouldn't be split to a separate package since this won't > provide any significant reduction in resource usage but only greatly > increase maintenance work and increase loading time due to dynamic > linking. > > Personally I want to put some of the most frequently used or the > smallest plugins (like kbled) back into the source tree of lxpanel. > > If there is no objections, I think it's the right time to do the merge > before lxpanel 0.5 release since all translations should be updated, > too. > > On Sun, Jul 5, 2009 at 9:55 PM, Marty Jack<[email protected]> wrote: >> Nothing good is achieved by having plugins duplicated between lxpanel and >> lxpanel-plugins. We have what is essentially an unmaintained fork of these >> plugins in lxpanel-plugins. As I pointed out before, it makes extra work >> for the translators, translating things that will never be shipped to >> customers. >> >> There is a lot of value in having a second tree for plugins that are in >> development, experimental, of less wide appeal, or otherwise not ready for >> the main tree. The development by Afirvida is an excellent example of this. >> Projects like gstreamer and compiz have this concept already where they >> have several grades of plugin tarballs. >> >> I would suggest we leave lxpanel-plugins for this second purpose and remove >> from it any plugin that is already resident in lxpanel. Over time plugins >> can migrate from lxpanel-plugins to lxpanel as they become stable and useful >> to a wide audience. >> >> I should also have mentioned the GTK requirement will be 2.14. With the >> introduction of GtkLayout for the icon grid I had to call something that is >> only in 2.14. >> >> PCMan wrote: >>> Amazing!!!! >>> Personally I agree with your changes. >>> I, however, have another suggestion. >>> Maybe we should fix the duplication of plugins in lxpanel trunk and >>> lxpanel-plugins first before this release. The source code in >>> lxpanel/src/plugins and lxpanel-plugins are currently our of sync. I >>> believe that it's the right time to solve this long standing issue >>> before 0.5 release. >>> >>> On Sun, Jul 5, 2009 at 7:25 AM, Marty Jack<[email protected]> wrote: >>>> Here are some release notes for the next round of lxpanel checkins. These >>>> are ready to go as soon >>>> as we agree on a release plan. >>>> >>>> Normally this might go in on a branch, but I consider it in code freeze >>>> rather than still in development. It is stable to the extent I can test >>>> it. I have been running most of it for over a week. I know it might >>>> impact some users who are used to building from SVN but I think I would >>>> suggest checking it in on trunk and having an intensive effort to test and >>>> stabilize and then put out a beta tarball. As we already know, the >>>> highest risk is a segfault that causes the panel to restart. Your >>>> feedback on the best way to get this done is welcomed. >>>> >>>> Icon grid layout manager >>>> >>>> A new layout manager for the Keyboard LED, Launchbar, Pager, and System >>>> Tray plugins adapts to the size of the panel and repacks icons to use >>>> space most efficiently. >>>> >>>> New handling of "stretch" >>>> >>>> Now only the Space and Taskbar plugins will honor "stretch" or offer it in >>>> the configuration dialog. For the Taskbar plugin, it is defaulted on to >>>> avoid having a new user encounter the behavior that the taskbar grows >>>> beyond its allocation. >>>> >>>> Honoring font color >>>> >>>> Font color is now honored in every plugin. Font color changes immediately >>>> in all plugins as it should. >>>> >>>> Desktop Number plugin >>>> >>>> Shows desktop names if available from window manager. >>>> >>>> Launchbar plugin >>>> >>>> Changed the handling of an empty launchbar. I was troubled by how it >>>> initially configured pcmanfm and firefox, which may not be installed and >>>> we would display the broken image icon. Now the plugin puts up an "Add" >>>> button when the launchbar is empty that takes the user to the >>>> configuration dialog. >>>> >>>> The launchbar configuration dialog now populates a list of available >>>> applications from the menu cache. It is no longer possible to add an >>>> application to the launchbar unless it is in the menu. However, users no >>>> longer have to search the file system for the desktop file if it is not in >>>> the particular directory that the plugin displayed in previous releases. >>>> >>>> The launchbar configuration dialog now displays the application icons. >>>> >>>> Menu >>>> >>>> Non-square icons now work. >>>> >>>> Fixed the handling when a menu plugin was created so that the broken image >>>> icon is not displayed. >>>> >>>> Pager >>>> >>>> Each desktop now has a tooltip with the desktop name as reported by the >>>> window manager. >>>> >>>> Removed the hardcoded limitation of 20 desktops. >>>> >>>> It is still a known issue that some Compiz features are unsupported. This >>>> is the next item to be worked on. >>>> >>>> Taskbar >>>> >>>> Removed the confusing options Accept SkipPager, Show Iconified, Show >>>> Mapped. >>>> >>>> Added an option to combine multiple windows from the same application into >>>> one button ("Grouping"). >>>> This should alleviate most issues with taskbar overcrowding. >>>> >>>> Significant internal reworking of the implementation. >>>> >>>> Tray >>>> >>>> Implemented so-called "balloon messages", small amounts of text that a >>>> tray application can display. >>>> >>>> Significant internal reworking of the implementation. >>>> >>>> Window Command >>>> >>>> Removed the "toggle" behavior. Now the plugin unconditionally iconifies >>>> or shades all windows on a left or middle click. >>>> >>>> Plugin development notes >>>> >>>> Vertical panels are now assumed to be fairly wide, and text is always >>>> drawn upright. I personally run with a vertical panel 150 pixels autohide. >>>> >>>> The plugin versioning proposal is implemented. External plugins will not >>>> load unless PLUGINCLASS_VERSIONING is called in the PluginClass >>>> initializer (and matches the version of the panel). >>>> >>>> Several plugins were found to call the destructor in the error path of the >>>> constructor. This is wrong and will cause a segfault later when the >>>> plugin manager calls it again. >>>> >>>> Plugins should not consider an unrecognized parameter a fatal error. This >>>> reduces the possibility that a user can fall back to an earlier release if >>>> trouble is encountered on an upgrade. >>>> >>>> The "orientation" callback is used whenever any style change is made that >>>> might require a full redraw, such as an orientation change or a text color >>>> change. The plugin should do a full redraw. >>>> >>>> Plugins should not destroy p->pwid in the destructor. This is done in the >>>> plugin manager. >>>> >>>> All text drawing should flow through the central routine >>>> panel_draw_label_{text,integer}. This centralizes the handling of font >>>> color. >>>> >>>> All right-click handling should flow through the central routine >>>> plugin_button_press_event. Plugins should declare this as the >>>> button-press-event handler if they do not have any other handling of >>>> button press. >>>> >>>> Plugins need to be careful to constrain the height of their top level >>>> widget, so they work properly in wide vertical panels. >>>> >>>> Test with both horizontal and vertical panels. Test with all background >>>> options. Test that your plugin works properly when it is removed from the >>>> panel. Run the panel from a terminal and make sure your plugin does not >>>> generate GTK assertions or X errors. >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Lxde-list mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/lxde-list >>>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Lxde-list mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/lxde-list >>> > ------------------------------------------------------------------------------ _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
