Putting the most frequently used plugins in lxpanel main trunk and making them static is a good idea. However, the unfinished netstat plugin and plugins requiring other dependencies, could be left in lxpanel-plugins.
Plugins which IMO should be statically linked. batt cpu deskno kbled volume volumealsa thermal Plugins left in lxpanel-plugins drives example gmenu2 menu_2 netstat xkb Any other comments? On Mon, Jul 6, 2009 at 11:28 PM, Marty Jack<[email protected]> wrote: > 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
