Re: [nebula-dev] PShelf now supports CSS
Hi, I haven't looked into PShelf already, but may I raise the question what is the difference between PShelf and SWT ExpandBar? Looking quite the same from not knowing details. But maybe I'm missting details. Greez, Dirk On Mon, Apr 8, 2013 at 3:23 PM, Tom Schindl tom.schi...@bestsolution.atwrote: Hi, I was approached by a customer last week who are using PShelf inconjunction with e4 and their problem was that the PShelf didn't adjusted itself when a different CSS was chosen but always used the System-Colors to calculate derived colors. I've just pushed the css support for nebula-pshelf into an extra bundle residing next to the pshelf widget itself. I hope other widgets will follow this and add CSS support to define property values. Thanks for revendex (http://www.revendex.com) to sponsor this work! The stuff is NOT yet included into the build, need to see how and where I add it. Tom Schindl __**_ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/**mailman/listinfo/nebula-devhttps://dev.eclipse.org/mailman/listinfo/nebula-dev ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev
Re: [nebula-dev] PShelf now supports CSS
It's a lot more themable than ExpandBar and it always only shows one of it's children. ExpandBar by default allows you to expand multiple ones. Tom On 09.04.13 11:44, Dirk Fauth wrote: Hi, I haven't looked into PShelf already, but may I raise the question what is the difference between PShelf and SWT ExpandBar? Looking quite the same from not knowing details. But maybe I'm missting details. Greez, Dirk On Mon, Apr 8, 2013 at 3:23 PM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: Hi, I was approached by a customer last week who are using PShelf inconjunction with e4 and their problem was that the PShelf didn't adjusted itself when a different CSS was chosen but always used the System-Colors to calculate derived colors. I've just pushed the css support for nebula-pshelf into an extra bundle residing next to the pshelf widget itself. I hope other widgets will follow this and add CSS support to define property values. Thanks for revendex (http://www.revendex.com) to sponsor this work! The stuff is NOT yet included into the build, need to see how and where I add it. Tom Schindl _ nebula-dev mailing list nebula-dev@eclipse.org mailto:nebula-dev@eclipse.org https://dev.eclipse.org/__mailman/listinfo/nebula-dev https://dev.eclipse.org/mailman/listinfo/nebula-dev ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev
Re: [nebula-dev] Future of Nebula
Thanks for the input and the offer for help Edwin. I agree with most of your ideas but I'm happy with the current state of our build and repo. Mickael? 2. Revamp the widget catalog. This is the first thing prospective users of Nebula will see, and it should convey accurate and useful information to them. +1 does anyone care to propose a format? a. Indicate who the lead maintainer is for each widget and provide contact info, or if there is no active maintainer indicate this as well. It's great that we have identified this already, but we should put this info into the catalog because it tells users how they can get support. Users are not going to dig through our wiki to find this info. I'm fine with this. Anyone objections? b. Provide links to the widget's source repo and ci build (see #1) c. Provide links to the bugzilla for each widget so users know how to submit bug reports and maintainers can see what needs to be done. sounds good. I think revamping the widget list and providing more info per widget is the next step. Regards, Wim ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev
Re: [nebula-dev] Future of Nebula
Hi, Sorry my comments are a bit late (Easter holiday/Spring break). From the consumer perspective, I agree that a table summarizing the purpose, features and state of widgets is important. I think a table with the following contents would be a good start: - widget name - one-liner describing purpose - SWT support (yes/no) - RWT/RAP support (yes/no) - JFace requirement (yes/optional/no) - CSS support, i.e. can be styled with CSS - lead maintainer - (separate) indication of maturity (e.g. alpha, beta, released, mature) and activity (e.g. inactive (dead?), stable (mainly bug-fixing), active (new features in development)) - links to example page, bugzilla, source repo, ... From the maintainer perspective I think it is important to allow for several models, from simple widget in common repo and little or no overhead, to separate project with own repo, releases and site. This ensures a low threshold for contributing, while allowing more complex projects to manage on their own without burdening the Nebula lead. Hallvard On 09.04.13 10.40, Wim Jongman wrote: Thanks for the input and the offer for help Edwin. I agree with most of your ideas but I'm happy with the current state of our build and repo. Mickael? 2. Revamp the widget catalog. This is the first thing prospective users of Nebula will see, and it should convey accurate and useful information to them. +1 does anyone care to propose a format? a. Indicate who the lead maintainer is for each widget and provide contact info, or if there is no active maintainer indicate this as well. It's great that we have identified this already, but we should put this info into the catalog because it tells users how they can get support. Users are not going to dig through our wiki to find this info. I'm fine with this. Anyone objections? b. Provide links to the widget's source repo and ci build (see #1) c. Provide links to the bugzilla for each widget so users know how to submit bug reports and maintainers can see what needs to be done. sounds good. I think revamping the widget list and providing more info per widget is the next step. Regards, Wim ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev -- Hallvard Traetteberg, Visiting Scholar at EECS, Univ. of California, Berkeley ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev
Re: [nebula-dev] Future of Nebula
- This includes updating the documentation regularly, speaking at conferences, writing blogs, adding more widgets - Improve project management Don't missunderstand me, you are doing a great job Wim, but the last year there was fairly no action in Nebula. At least none that was promoted strongly. Agreed. I have been trying to start some activities during the last year but I must admit that I feel that I cannot seem to find the right tone to build momentum for the project. That is one of the reasons why I started this thread. ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev
Re: [nebula-dev] Future of Nebula
Hi Hallvard, Thanks for joining the discussion. On Tue, Apr 9, 2013 at 8:42 PM, Hallvard Trætteberg h...@idi.ntnu.no wrote: Hi, Sorry my comments are a bit late (Easter holiday/Spring break). From the consumer perspective, I agree that a table summarizing the purpose, features and state of widgets is important. I think a table with the following contents would be a good start: - widget name - one-liner describing purpose - SWT support (yes/no) - RWT/RAP support (yes/no) - JFace requirement (yes/optional/no) - CSS support, i.e. can be styled with CSS - lead maintainer - (separate) indication of maturity (e.g. alpha, beta, released, mature) and activity (e.g. inactive (dead?), stable (mainly bug-fixing), active (new features in development)) - links to example page, bugzilla, source repo, ... Yes, there seems to be consensus about this. I will start this effort. From the maintainer perspective I think it is important to allow for several models, from simple widget in common repo and little or no overhead, to separate project with own repo, releases and site. This ensures a low threshold for contributing, while allowing more complex projects to manage on their own without burdening the Nebula lead. I agree. This is more or less like we do it now. Edwin? ___ nebula-dev mailing list nebula-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/nebula-dev
