new UI material design / paper / polymer
Opened this issue · 7 comments
In order to do #56 (convert to android app using mobilechromeapps) I'll need a more mobile suitable UI.
Trying out Polymer components in another app I'm working on (kzahel/spotubify#1). I'm using bower there. I'm hoping to keep bower out of this project so users can still download the "Zip" file and not have to worry about dependencies and having node/npm etc. Maybe use github "releases" feature instead, and have a bower.json checked in here. not sure yet
Hey, I'm new to this GitHub thing. Is there a plan for the color scheme?? Or are you following the current scheme?
I don't pay much attention to the latest developments in chrome OS design or the color scheme. What would you recommend?
How is this coming along? I'd be willing to assist on this if you give me some pointers on what it is exactly you would like to achieve... Just turning the various UI components into polymer components? How much of the logic would you like to turn into components?
I haven't had much time to work on this. I did some testing with Polymer components and found it was still a little rough integrating with packaged apps (mostly designed for web pages)
There is already a pretty clear separation between the view and the actual torrenting logic (you can see there are already two views, minimized and normal) so adding a third view wouldn't be too bad. I think it would be good to do some more experimenting.
I'm concerned that there may not be a good performing list view in Polymer that does lazy DOM creation/rendering. This is pretty much essential if you want the app to still be responsive with rendering lists of items with thousands of items (e.g. list of files in a torrent, or list of peers, etc). But maybe there is...
I haven't really worked on packaged apps in combination with polymer, so
that's something that I would have to experiment with...
Concerning a lazy-loading list view: I don't believe it should be that hard
to create a webcomponent that can handle that... I'll try to implement
something like that first thing when I start experimenting (although it
might be a while until I can get round to it...)
Op maandag 23 februari 2015 heeft Kyle Graehl notifications@github.com
het volgende geschreven:
I haven't had much time to work on this. I did some testing with Polymer
components and found it was still a little rough integrating with packaged
apps (mostly designed for web pages)There is already a pretty clear separation between the view and the actual
torrenting logic (you can see there are already two views, minimized and
normal) so adding a third view wouldn't be too bad. I think it would be
good to do some more experimenting.I'm concerned that there may not be a good performing list view that does
lazy DOM creation/rendering. This is pretty much essential if you want the
app to still be responsive with rendering lists of items with thousands of
items (e.g. list of files in a torrent, or list of peers, etc)—
Reply to this email directly or view it on GitHub
#72 (comment).
Met vriendelijke groet,
Adriaan Callaerts
It might be the default behavior for the polymer list view to be lazy loaded. I'm not sure. I didn't experiment with it enough to determine whether that was the case.
Last time I worked with polymer you had to run a (manual/hacky) compilation step because packaged apps don't allow any inline javascript and all the polymer components are packaged that way.
Tried to do another polymer interface thing, but the data table elements are still not mature enough. I made some improvements to the styles at least, to make them a little more "flat"