Re: [Lxde-list] LXSession and lxde-common are going to have new release recently.

[PCMan <pcm...@gm...>]

This is a nice and exciting list. Thanks Marty.
This seems to be a total rewrite rather than "improvement" and this
will be totally backward-incompatible. So it's good that you talk
about this in the mailing list earlier. Otherwise if people are
working on the same part, it'll be a disaster later and can cause
various conflicts.
On Tue, Apr 27, 2010 at 7:18 PM, Marty Jack <mar...@co...> wrote:
>> It's always better for you to talk about what you're working on the
>> mailing list if you are reluctant to put them in git branches.
>> Otherwise there is no way for others to cooperate with you easily.
> Okay, here you go.  Anything above the "Planned but Unfinished" is already working.  It is not nearly stable enough for anyone else to bother with yet, but it gets better and more feature complete every day.
>
> Architectural improvements
>        Do not treat dynamic memory allocation and gtk_image_set_from_file as if they were free
>        Do not hold glib in reverence; go outside it as needed
Can you be more specific on this? What you actually mean?
>        Use threads where they are the best answer (volume, inotify)
Why it's the best answer?
>        All drawing done with Cairo and Pango and with custom widgets LXButton, LXGrid, LXSocket that always do the right thing
totally agree on this one
>        Proper plugin API, documented, supported, so plugins don't crawl all over internal structures
This is needed. Should we use gtk-doc?
>        Single set of data structures built by single panel wide event handler so every plugin doesn't build their own
>        Plugin private data co-located with central data structure, streamlined event delivery
>        Centralized handling of properties and property read/write, data conversions: good high-level plugin API
I think the properties handling API of gobject is quite high-level and
that's why I propose it earlier. Reuse existing technology whenever
possible is also one of our principles. But if you really have better
solution, I'll use yours.
>        lxpanel + lxsession + menu-cache + lxsession-edit + lxshortcut unified to one process to share implementation and avoid different bugs in the different parts
Actually I'm thinking about this, too. However this will kill the
modularity of LXDE. This approach is what ROX desktop use.
Pros:
1. All core components are in the same process. The startup can be
much faster and resource usage can be minimal since things are all
shared among all compoents.
Cons:
1. One component crashes, the whole DE crashes. This is just like the
Windows explorer.exe, which contains all core components, too. At
least LXSession should be separated.Otherwise any part of it crashes,
such as a panel plugin containing bugs, this can crash the whole
desktop session. So I don't agree with this one. It's not possible to
create a bug-free program and assume it never crash no matter how
skillful you are.
2. If you really want to do it, put every components in shared libs
instead of just compiled them together. So it's possible to load them
in another processes with small stub programs. Those core components
can be loadable modules of desktop session process, or they can be
loaded in separate process and work independently, too. The we keep
the original modularity, and you can also load them all in one process
to make it monolithic.
3. LXSession shouldn't be part of it since this is a rarely used tool
and it's not needed to leave is resident in memory all the time. A
separate program for it is enough. If you need to run it in the same
process, put it in loadable module solve this. So we can have it in
process, and can unload it when it's not needed. This is another
advantage of what I mentioned in #2.
>        Threaded very fast menu processor, menu reload, and properly synchronized data structure:  Dispense with menu cache, never saw it take more than 500 ms
Have you done this?
> User visible improvements
>        True alpha support with compositing window manager
>        Manual Hide plugin
>        Enumerator for sensor in Thermal plugin; now based on libsensor
>        Complete EWMH viewport support in Desktop Number, Pager, Taskbar plugins
>        Independent control over text size
>        Independent control over text size in Digital Clock plugin
>        Decreased memory usage: measure this
>        Sorted list and display of description in Add Plugin
>        Sorted list in Directory Menu plugin (this was backported to LXPanel)
>        Configuration in a single file to reduce clutter and startup time; using XML for standards compliance
>        Graphical configuration for formerly-lxsession parameters: window manager, quick-autostart, FDO autostart
>        CPU Frequency plugin works, displays all CPUs, but cannot change governor; this would require root access
>        Plugin that fails to initialize displays Error icon rather than failing to display anything
>        User-specified label on Menu plugin, works like Directory Menu plugin
>        Menu plugin has Add to Autostart in the right-click menu; can also do from Panel Preferences
>        Proper sensitivity of buttons in Plugin configuration, Launchbar configuration, new Autostart configuration
>        Consistent treatment of Available list in Plugin, Launchbar, Autostart; left/right panel presentation
>        Taskbar plugin style where it has windows in a menu and only shows the icon of the one with focus; integrated so you can select either, unlike other DEs
>        Debugging mode that can run in parallel with another panel: disables autostart, root window selection, Xsettings
>
> Planned but unfinished as of today
>
>        Proper shutdown sequencing with SIGTERM and SIGKILL
>        Device enumeration in Volume Control
>        Visual indication when an item can't be launched rather than failing silently
>        Editor for non-.desktop commands in Launchbar, Menu, and Autostart
>        Full FDO Menu including Merge, Move
This is supported by menu-cache already. There is no problem with it
since that part is taken from gnome-menus.
>        Full FDO menu editor, one so nice that other DEs would want because you can see why your menu isn't working the way you expect
This is an accepted GSoc project and Shae will work on this this
summer. So you don't need to do this part. Or, you can help Shae to do
this part.
>        Corner collisions
>        A11Y in LXButton and LXSocket
>        Netstat rethink completely
>        Battery convert over to UPower so people don't run gnome-power-manager (Eugene working on?)
>        Unify lxinput, lxrandr, lxappearance, anything else that is needed but unavailable now, and the menu editor under a configuration GUI
This has been done by pcmanfm menu://applications/DesktopSettings/ already.
> Possible future
>        CPU plugin has other graphs available like the one in Gnome
>        Multiple screen support: need an ongoing way to test
Since none of us have working multiple screen setup, it's very hard to
overcome this part. Any suggestions?
>        A way to authenticate or access a sudo program for things that need root access like changing the date
Policykit might be needed for this. Since it's not quite possible to
get rid of it completely since udisks and upower already require it,
we can utilize existing technology if this doesn't bring much
performance degradation. We already have our own policykit agent. So
utilizing policykit is not a problem. However, I don't like the
"unlock" button designed by gnome. It's quite unnatural for a ordinary
user to "unlock" first and to use a dialog. If I'm a beginner, I'll
think that the program is broken, so every widget on the dialog is
disabled. I won't know that I need to click on "unlock" first and
enter my password. So I don't like that design.