What about simplifying the core lib with oo? about powerline HOT 9 CLOSED

I'm not sure about what you mean with the function generator? I agree that the project should be restructured somewhat because it has evolved quite a bit from the initial concept. A problem I've run into working on this is that abstracting the project too much can have a serious impact on performance. Initially we had a Segment class, but I had to change that to the mksegment function that returns a plain dict. This sped up the application considerably, so my worry is that if we abstract this too much it would introduce lag in applications like vim. Remember that this code is run many times each second when travelling through vim buffers and I'd like to keep the CPU usage as low as possible.

That being said, I like the suggested structure, and I agree that we could try to restructure the tasks of the classes so the core class handles a Theme and a Colorscheme class and the format, while the renderer class actually handles the rendering instead of the render method of the Powerline class. Feel free to try to reorganize the code, but please avoid the **kwargs, I think it's better to include specific arguments based on the current state of the config format (the gist in #2). We can change the method arguments later if the config format is changed anyways.

from powerline.

Here's my proposed change to the file structured based on your suggestions:

README.rst
powerline/
    colorscheme.py - cterm2hex array and colorscheme loader
    core.py - Powerline class, loads theme/colorscheme and renderer
    renderer.py - main segment renderer, like the Powerline.render() method
    segment.py - mksegment()
    theme.py - theme loader
    extensions/
        vim/
            bindings.py - vim python bindings
            renderer.py - vim renderer, extends Renderer, handles hi group generation, etc
            segments/
                core.py - vim core segments
        zsh/
            ...
        tmux/
            ...

What do you guys think?

Edit: Did a quick test here: https://github.com/Lokaltog/powerline/tree/feature/project-restructuring

from powerline.

Thanks for your answer. I knew that adding too complex a class structure may slow it down a bit, and it's good to know you tried it and had to do it the current way for speed. So, I might wait before trying to profile a more structured system.

That being said, your point about vim calling powerline multiple times a second is important. Could we consider implementing some form of timers to some slower segments? For example, most git related scripts will tend to be slower than a pwd wrapper, so it could benefit from a slight lag in update time. Each segment could have a default 100ms recall lag with the ability to specify. One prime example is weather (like in tmux-powerline) because rss providers request you not ping their servers erratically. Therefore you need multiple minutes or even hours between retrievals depending on the server.

I like your refined package tree. It would make it great with a setup.py in the root directory so that you can install it and access it from the python site-packages folder (or from PYTHONPATH). Also, do you plan to have a theme folder that holds some default and user-submitted themes to act as guides or drop and play? Perhaps the folder could be moved to ~/.powerline and then individual preferences can be pulled out or some variant of this.

from powerline.

I absolutely agree with your idea of a timer, there are two segments in particular that are super resource intensive, one is the fugitive segment, the other is the tagbar currenttag segment. I'd like to increase the update delay for both those to maybe once a second or something like that. I have no idea how to make that work though, so if you're up for the task, please go ahead and implement it.

The idea with the updated tree was as you mention making it more like a regular Python package. I'm also planning on including some Sphinx docs and unit tests later as well, and the updated file structure would work better with that as well. Making Powerline accessible from the site-packages folder is a great idea, and it could simplify user installation considerably if we can upload it to PyPI and maybe provide distro packages later on when the project is out of beta.

Regarding themes and colorschemes, I have considered adding those to $XDG_CONFIG_HOME/powerline/{themes,colorschemes}, but I'm not sure if this is supported on OS X and it's certainly not supported on Windows so we'd have to handle each OS differently for it to work.

from powerline.

I just checked $XDG_CONFIG_HOME is not set in my environment on OSX, but typically a lot of programs (i.e. ipython) use $HOME/.config for default config file installation. I think this could be a good location in the event that $XDG_CONFIG_HOME is unknown, but windows does not hide dot-files, so I'm not sure where it should go in other os's.

Edit: I'll be thinking about how such a timer could be setup, and if I can get an idea of something I'll give it a shot.

from powerline.

Allright. $XDG_CONFIG_HOME usually corresponds with $HOME/.config, so if the convention on OS X is the same then we could just fallback to $HOME/.config if $XDG_CONFIG_HOME isn't set. Windows won't be a priority as I have the impression that only a tiny minority use Windows for development at all, and I'm not sure if vim for Windows even includes Python support. Windows wasn't officially supported in the other Powerline project either, so I don't see it as a big issue.

from powerline.

Another question: Where should we put the default colorscheme and theme? The colorschemes aren't extension specific, but the themes are. I have a couple of ideas, but I'm not sure which one would work the best:

/powerline/colorschemes/default.json
/powerline/themes/{vim,terminal,zsh}/default.json

/colorschemes/default.json
/themes/{vim,terminal,zsh}/default.json

/powerline/colorschemes/default.json
/powerline/extensions/{vim,terminal,zsh}/themes/default.json

I'm leaning towards number 1 because the structure also works well when mirrored to the user config dir:

~/.config/powerline/colorschemes/mycolorscheme.json
~/.config/powerline/themes/{vim,terminal,zsh}/mytheme.json

from powerline.

I've implemented most of this stuff in 98337d2. It allows user configurations to be stored in ~/.config/powerline (or $XDG_CONFIG_HOME if it exists), and provides default configurations in a similar directory structure. Much of the code has also been refactored, it would be nice if you have time to take a look at it and give me some feedback on what you think. :)

from powerline.

Closing this since everything has been implemented and merged into develop.

from powerline.